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ABSTRACT 


The  United  States  Coast  Guard  Port  State  Control  (PSC)  is  a  port  entry  tracking 
process,  which  is  currently  performed  primarily  using  paper  and  pencil.  This  thesis 
examines  the  feasibility  and  effectiveness  of  redesigning  the  PSC  process  in  light  of 
modem  Business  Process  Redesign  methodologies  that  incorporate  contemporary 
information  technology.  The  current  process  is  modeled  using  the  automated  redesign 
tool,  KOPeR,  to  identify  pertinent  redesign  recommendations.  A  redesign  of  the  process 
is  completed  using  the  recommendations  provided  by  KOPeR  and  leveraging  existing 
Coast  Guard  infrastructure  and  technology  solutions.  The  effectiveness  of  the  redesigned 
process  is  evaluated  against  the  current  process  by  using  discrete  event  simulation  models 
to  compute  the  relative  cycle  times.  Three  different  scenarios  are  mn  which  show  a 
potential  armual  reduction  in  manpower  ranging  from  two  to  four  person  years.  A  Web- 
based  prototype  system.  Re-engineered  Port  System  (RePortS),  is  developed  using  basic 
tools  such  as  Microsoft  Access  and  Active  Server  Pages  to  demonstrate  the  feasibility  of 
implementing  the  required  functionality.  The  benefits  of  replacing  the  current  manual 
system  with  a  Web-based  system  are,  reduced  cycle  time,  increased  accuracy  and 
consistency  in  the  process. 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  United  States  Coast  Guard  (USCG)  is  charged  by  Congress  to  ensure  that 
foreign  flagged  vessels  entering  US  ports  are  adhering  to  US  laws  and  International 
treaties.  To  complete  this  mission,  the  Coast  Guard  has  created  the  Port  State  Control 
(PSC)  program  to  board  foreign  vessels  to  ensure  compliance.  The  current  process  of 
gathering  vessel  port  call  information,  deciding  which  vessels  to  board,  boarding  them, 
and  then  docixmenting  the  boarding  is  largely  completed  using  paper  and  pencil.  This 
leads  to  a  process  that  takes  considerable  time  and  leads  to  multiple  errors  and  rework 
due  to  the  number  of  times  data  must  be  manually  transferred.  Such  a  process  is  an  ideal 
Business  Process  Reengineering  (BPR)  candidate  because  of  the  opportunity  to  reduce 
cycle  time  and  data  collection  errors. 

The  Coast  Guard  recently  initiated  a  BPR  of  the  PSC  process  in  conjunction  with 
a  large  software  project  to  replace  a  legacy  vessel  database  system  running  on  Prime 
computers.  The  BPR  was  performed  by  personnel  at  Coast  Guard  Headquarters 
interviewing  field  units  experienced  in  performing  the  tasks  involved  in  the  PSC  process. 
From  this  BPR,  a  set  of  use  cases  was  developed  to  assist  the  contractor  in  writing  the 
software  to  implement  the  new  process.  Unfortunately,  the  contract  was  terminated,  and 
replaced  by  a  much  smaller  project  undertaken  whose  scope  was  simply  to  replace  the 
functionality  of  the  legacy  database  with  a  database  running  on  a  modem  platform.  The 
additional  functionality  associated  with  the  BPR  for  the  PSC  process  and  other  areas  of 
functionality  are  planned  as  incremental  changes  to  the  new  database  over  a  period  of 
time.  This  provides  an  opportunity  to  perform  an  independent  BPR  using  current 
methods  in  order  to  provide  alternative  solutions  for  the  eventual  implementation  of  the 
redesign. 

The  main  purpose  of  this  thesis  is  to  analyze  and  perform  a  business  process 
redesign  (BPR)  of  the  U.  S.  Coast  Guard  Port  State  Control  (PSC)  process.  The  focus  of 
this  research  is  to  provide  innovative  solutions  that  dramatically  improve  the  cycle  time 
and  data  accuracy  of  the  process. 
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B.  PURPOSE 


This  research  examines  the  U.S.  Coast  Guard’s  Port  State  Control  process  at  the 
field  unit  level.  The  objective  is  to  significantly  improve  the  critical  measures  of 
performance,  in  terms  of  cycle  time  and  data  integrity,  by  redesigning  the  current  process. 

Presently,  the  Coast  Guard  is  designing  a  new  enterprise  database  application, 
called  the  Marine  Safety  Network  (MSN),  which  will  support  parts  of  the  PSC  process. 
While  early  versions  of  the  MSN  will  not  include  the  types  of  functionality  presented  in 
this  research,  it  is  anticipated  that  future  releases  of  the  MSN  can  implement  features 
discussed  in  this  study.  Further,  the  redesign  methods  outlined  in  this  thesis  can  be 
applied  to  other  similar  marine  safety  processes  where  similar  improvement  can  be 
realized. 

C.  SCOPE  AND  METHODOLOGY 

This  study  focuses  on  the  state  and  the  inefficiencies  of  the  current  PSC  process 
and  ways  to  eliminate  or  reduce  the  effects  of  these  inefficiencies.  The  primary  objective 
is  to  define  the  process  and  perform  a  redesign  that  improves  performance. 

The  process  under  study  consists  of  an  administrative  activities  portion  and  a 
physical  inspection  of  a  vessel.  This  thesis  covers  only  the  administrative  portion  of  the 
process.  The  prototype  developed  for  the  redesign  process  will  consist  only  of  those 
elements  needed  to  implement  a  working  demonstration  of  the  redesigned  process.  It  will 
therefore  not  include  encryption/security  features,  full  implementation  of  all  features  of 
the  redesign  and  any  field  testing  of  the  prototype. 

The  methodology  followed  in  fulfilling  the  objective  consists  of  several  steps: 

1.  Conduct  a  literature  search  of  current  BPR  methodologies  and  associated 
technologies,  and  select  a  BPR  methodology  for  the  redesign  of  the  process. 

2.  Conduct  a  review  of  Coast  Guard  instructions  and  directives  pertaining  to  the 
PSC  process. 

3.  Identify  and  model  the  current  state  of  the  PSC  process. 
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4.  Identify  and  analyze  the  pathologies  and  problems  with  the  current  PSC 
process. 

5.  Redesign  the  PSC  process  to  improve  process  cycle  time  and  data  collection 
accuracy. 

6.  Create  simulation  models  of  the  current  and  redesigned  processes  to  assess  the 
effectiveness  of  the  redesigned  process. 

7.  Create  a  prototype/proof  of  concept  of  the  redesigned  process  using  web 
enabled  database  technology. 

D.  ORGANIZATION  OF  STUDY 

The  thesis  is  organized  as  follows.  Chapter  II  provides  an  overview  of  the  PSC 
process  and  BPR.  Chapter  III  contains  a  logical  breakdown  of  the  process  and  models  of 
the  sub-processes  using  simple  diagrams  and  the  diagnosis  of  the  processes.  Chapter  IV 
contains  the  proposed  process  redesigns  and  simulation  models  of  the  proposed  and 
current  processes.  Chapter  V  describes  the  software  prototype  architecture  and 
implementation.  Chapter  VI  summarizes  the  conclusions  and  recommendations. 
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II.  PROCESS  OVERVIEW 


A.  THE  PORT  STATE  CONTROL  PROCESS 

To  understand  the  genesis  of  the  current  PSC  process,  it  is  necessary  to  review  the 
organizational  structure  and  history  of  the  US  Coast  Guard  Marine  Safety  program.  The 
Coast  Guard  has  established  Marine  Safety  Offices  (MSO)  in  the  major  port  areas  in  the 
US  to  carry  out  the  missions  of  the  Marine  Safety  program. 

Prior  to  the  establishment  of  MSOs,  the  Marine  Safety  program  was  administered 
by  two  separate  commands  in  the  major  port  areas.  These  commands  were  the  Captain  of 
the  Port  (COTP)  and  the  Officer  in  Charge,  Marine  Inspection  (OCMI)  respectively.  The 
major  responsibilities  of  the  COTP  were  port  security,  port  safety,  and  marine 
environmental  response/prevention.  The  OCMI  was  responsible  for  the  inspection  of  US 
flagged  vessels,  investigating  marine  casualties  and  the  licensing  of  US  Merchant 
Mariners.  Due  to  budgetary  pressures  and  the  economies  of  having  a  single  command 
versus  two  separate  commands,  it  was  decided  to  merge  the  two  different  commands  into 
one  with  the  Commanding  Officer  performing  both  roles  of  COTP  and  OCMI.  The 
resulting  command  was  called  an  MSO. 

The  current  Coast  Guard  PSC  process  has  its  roots  in  a  precursor  program  called 
the  Foreign  Vessel  (FV)  boarding  program.  The  goal  of  the  FV  program  was  to  ensure 
foreign  registered  vessels  were  complying  with  US  laws  and  regulations  while  in  US 
waters.  The  program  at  most  MSOs  was  carried  out  by  the  Port  Operations  Department, 
which  is  the  COTP  arm  of  the  MSO.  The  boardings  of  the  vessels  were  carried  out  by 
Petty  Officers  who  usually  had  a  couple  of  months  of  on  the  job  training,  specific  rate 
experience,  and  time  spent  at  a  Marine  Safety  “C”  school  for  program  familiarity.  This 
program  worked  well  in  enforcing  the  pollution  prevention  and  navigation  safety 
regulations  on  the  foreign  vessels  calling  at  US  ports. 

With  the  increase  in  global  competition  and  increasing  costs  associated  with 
operating  a  US  registered  vessel,  the  US  deep  draft  vessel  fleet  was  on  the  decline.  By  the 
mid  to  late  1980’s  the  majority  of  vessels  calling  on  US  ports  were  foreign  registered 
with  the  majority  being  registered  in  a  country  with  low  registration  costs  and  less 
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stringent  safety  standards.  The  monetary  rewards  of  registering  a  vessel  in  one  of  these 
“flags  of  convenience”  were  substantial  and  the  registries  of  these  countries  grew 
dramatically. 

In  1993  there  was  a  series  of  incidents,  the  most  notable  being  a  hazardous 
materials  spill  off  of  the  New  Jersey  coast,  involving  foreign  registered  vessels  in  US 
waters  that  had  been  recently  boarded  by  different  MSOs.  These  incidents  caught  the 
attention  of  Congress,  which  held  hearings  on  the  matter.  It  was  found  that  there  needed 
to  be  a  more  in  depth  inspection  of  the  foreign  vessels  calling  on  US  ports  and  that  these 
inspections  needed  to  be  carried  out  by  more  experienced  personnel.  In  the  1994 
Department  of  Transportation  Appropriations  Bill,  the  Congress  mandated  that  the  Coast 
Guard  change  its  approach  to  foreign  vessel  boardings  to  “hold  those  most  responsible 
for  substandard  ships  accountable,  including  owners,  classification  societies  and  flag 
states.”  (U.  S.  Coast  Guard  Marine  Safety  Manual  Vol.  11,  Chap  23)  Thus,  the  current 
PSC  program  was  bom. 

The  organizational  difficulties  of  persuading  the  Port  Operations  Department  and 
the  Vessel  Inspections  Department  (the  OCMI  arm  of  the  MSO)  to  agree  initially  on  who 
should  control  the  program  were  problematic.  Nevertheless,  differences  were  ironed  out 
and  workable  solutions  to  the  organizational  stmcture  were  generated  independently  in 
each  port  area.  This  resulted  in  each  MSO  performing  the  PSC  program  differently  and 
interpreting  guidance  as  they  saw  fit,  which  resulted  in  the  program  being  applied 
inconsistently  nationwide.  Recognizing  this.  Coast  Guard  Headquarters  published 
guidance  and  requirements  on  how  to  perform  the  program  to  meet  key  goals. 

1.  Description  of  the  Current  Process 

The  majority  of  the  mechanics  of  the  PSC  program  and  its  associated  processes  is 
spelled  out  to  field  units  in  the  USCG  Marine  Safety  Manual,  Volume  11,  Chapters  19 
through  24.  There  are  other  vessel  inspection  oriented  instructions  relating  to  the  PSC 
program,  but  they  are  not  germane  to  the  administrative  processes  that  constitute  the 
focus  of  this  research. 
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In  order  for  field  units  to  successfully  execute  the  PSC  program,  a  process  must 
be  followed  which  allows  the  unit  to  identify  vessels  requiring  boardings,  perform  the 
boarding  and  then  document  the  boarding.  This  process  is  the  focus  of  this  thesis. 

Figure  2.1  depicts  a  general  overview  of  the  PSC  process.  A  short  explanation  of 
each  step  is  provided  for  clarification  and  a  full  explanation  of  each  step  will  follow  in 
Chapter  3. 

1 .  The  process  begins  with  a  vessel  agent  calling  either  a  Coast  Guard  point  of 
contact  or  a  centralized  broker  of  vessel  arrivals  to  report  the  arrival  of  a 
vessel. 

2.  The  pertinent  data  on  the  vessel  is  recorded  on  a  log  sheet  and  held  until  the 
PSC  section  personnel  gather  the  log  sheets  periodically  through  out  the  day. 

3.  One  of  the  personnel  in  the  PSC  section  enters  the  vessel  arrival  information 
from  the  log  sheets  into  the  Coast  Guard  Marine  Safety  Information  System 
(MSIS)  and  prints  a  history  of  each  vessel’s  previous  port  calls  and  boardings 
throughout  the  US. 

4.  Based  on  information  from  the  history  of  the  vessel,  a  grading  sheet  is 
prepared  to  determine  the  priority  of  the  vessel  for  boarding. 

5.  The  resulting  information,  vessel  name  and  priority  are  entered  into  another 
log  based  on  the  arrival  date  of  the  vessel. 

6.  A  supervisor  then  reviews  the  completed  grading  sheets  and  histories. 

7.  Based  on  vessel  priorities,  dates  of  arrival,  and  number  of  personnel  available, 
boarding  decisions  are  made. 

8.  Vessel  boarding  teams  are  then  dispatched. 

9.  On  board  the  vessel,  the  boarding  team  verifies  the  various  information  about 
the  vessel  against  the  history  pulled  from  MSIS.  Changes  to  the  information 
and  the  results  of  the  boarding  itself  are  recorded  in  a  “boarding  book”  as 
documentation  of  the  boarding. 
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10.  When  the  boarding  is  complete,  the  boarding  team  leaves  a  hand  written 
boarding  letter  with  the  Master  of  the  vessel  detailing  the  results  of  the  exam 
and  listing  discrepancies  found,  if  any. 

11.  Once  back  at  the  office,  the  boarding  team  then  prepares  the  documentation  of 
the  vessel  boarding.  This  entails  entering  the  hand  written  changes  to  vessel 
information,  the  results  of  the  boarding,  and  any  discrepancies  into  MSIS. 

12.  Once  the  data  entry  is  complete,  all  information  changed  in  MSIS  is  printed 
out  for  inclusion  in  the  local  vessel  paper  file. 

13.  Both  the  print  outs  and  the  vessel  “boarding  book”  are  submitted  for  review. 

14.  After  the  supervisor  has  reviewed  and  approved  the  boarding  package,  it  is 
filed  with  all  vessel-boarding  documents  in  a  local  filing  system. 

15.  For  vessels  not  boarded,  an  entry  is  made  in  MSIS  to  indicate  the  vessel  made 
a  port  call,  but  was  not  boarded. 

2.  The  Goals  of  the  PSC  Process 

The  overarching  goal  of  the  PSC  program  is  to  eliminate  substandard  vessels  from 
US  waters  (U.  S.  Coast  Guard  Marine  Safety  Manual,  Vol.  II).  The  subgoals  for  the  PSC 
process  are  efficiency,  timeliness  and  accuracy  in  the  following  areas: 

1 .  Identification  of  vessels  requiring  boarding. 

2.  Gathering  of  data  on  the  current  state  of  a  vessel  being  boarded. 

3.  Documentation  of  vessel  boardings. 
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Figure  2-1.  The  PSC  Process 
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3.  Critical  Performance  Measures 

In  order  for  the  PSC  process  to  perform  optimally,  the  subgoals  outlined  in  the 
preceding  section  must  be  met.  If  they  are  not,  time  and  resources  will  be  wasted,  not 
only  by  the  Coast  Guard,  but  also  by  the  vessel  inconvenienced  with  an  unnecessary 
boarding. 

Based  on  the  subgoals  it  is  clear  that  cycle  time  and  data  accuracy  are  the  critical 
performance  measures  for  this  process.  Cycle  time  is  the  time  required  to  complete  the 
process,  from  the  time  the  vessel  agent  calls  in  the  vessel  arrival,  to  the  completion  of  the 
documentation  of  the  vessel  boarding.  Cycle  time  is  measured  for  each  subprocess  as 
described  in  Chapter  III.  Data  accuracy/redundancy  is  measured  by  the  number  of  times 
identical  data  has  to  be  copied  from  one  piece  of  paper  to  another  or  input  into  a  database. 
The  data  accuracy  measure  is  taken  for  each  subprocess. 

B.  BUSINESS  PROCESS  REENGINEERING 

Business  Process  Reengineering  has  occupied  a  dominant  spot  in  the  IT  landscape 
throughout  the  1990s.  Due  to  the  amount  of  attention  given  to  the  BPR  movement  many 
different  BPR  methodologies  have  evolved  ranging  from  extreme  to  very  mild  with 
respect  to  the  degree  of  changes  to  processes  and  expectations  of  improvement.  This 
section  provides  a  brief  introduction  to  BPR,  a  look  at  several  different  BPR  approaches, 
a  brief  introduction  to  the  chosen  redesign  methodology,  and  an  evaluation  of  the 
applicability  of  the  chosen  methodology  to  the  PSC  process. 

1.  Reengineering  Overview 

When  introduced  by  Davenport  and  Short  (1990)  and  Hammer  (1990),  the  term 
business  process  reengineering  applied  to  a  radical  and  far-reaching  overhaul  of  a 
business  process.  Since  that  time  the  term  has  become  more  generic  and  now  includes  a 
broader  mix  of  methods  for  process  redesign,  which  range  from  the  original  meaning  to 
simple  process  improvement  techniques.  (Baden  and  Peters,  1997,  p51)  While  there  are 
many  different  reengineering  methodologies,  these  methodologies  can  be  categorized  into 
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one  of  three  different  approaches:  Continuous  Process  Improvement,  Business  Process 
Redesign  and  Business  Process  Reengineering.  While  each  approach  is  different  in  the 
amount  of  change  it  tries  to  effect,  the  goal  remains  the  same,  namely  to  change  the  way 
the  business  is  organized  to  perform  its  work  processes.  “Most  reengineering 
methodologies  investigate  ways  to  eliminate  non-value  added  processes,  utilize 
information  technology  to  minimize  redundant  data  entry  and  storage,  integrate  or 
combine  similar  processes,  implement  data  sharing,  and  automate  manual  processes.” 
(Baden  and  Peters,  1997,  p51)  Table  2-1  compares  the  major  features  of  the  three 
approaches. 

2.  Business  Process  Reengineering  Approaches 

Before  selecting  a  specific  methodology  to  use  in  the  redesign  of  the  PSC  process, 
it  is  important  to  understand  where  in  the  spectrum  of  approaches  a  redesign  lies. 
Additionally,  it  is  important  to  understand  the  crucial  differences  between  the  three 
different  approaches. 

Business  Process  Reengineering  is  “the  fundamental  rethinking  and  radical 
redesign  of  business  processes  to  achieve  dramatic  improvements  in  critical, 
contemporary  measures  of  performance,  such  as  cost,  quality,  service  and  speed.” 
(Hammer  and  Champy,  1993,  p32)  The  basic  premise  is  to  take  a  process,  identify  the 
desired  outcome,  and  build  a  new  process  “rejecting  the  conventional  wisdom  and 
received  assumptions  of  the  past.”  (Hammer  and  Champy,  1993,  p49)  The  result  is  a 
process  that  provides  a  quantum  leap  in  performance  and  may  change  the  entire  structure 
of  the  organization.  This  approach  is  not  without  its  risks  because  of  the  vast  changes  it 
endorses  and  the  potential  costs  associated  with  implementing  a  radically  new  process. 
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1  Features 

Continuous  Process 
Improvement 

Business  Process 
Redesign 

Business  Process 
Reengineering 

Philosophy 

Improve  what  you  do  in 
functional  or  sub- 
activity;  Accepts  status 
quo  -  current  processes 
are  what  customers  need 

Accepts  current  process: 
Remove  “hand  off’ 
activities  of  little  value 
in  an  end-to-end 
examination 

Focus  on  critical  broken 
processes:  Alter  or 
replace  basic  approach 
to  doing  business  in 
jobs,  skills,  structures, 
systems,  culture 

Timing 

Part  of  a  way  of  life  to 
continuously  improve; 
project  results  in  short 
time  frames 

Done  on  a  periodic 
basis;  improvement  may 
take  a  few  months  for 
simple  efforts;  1  to  2 
years  if  efforts  are  more 
complex 

Used  selectively;  sub¬ 
process  deployment  may 
take  several  months;  full 
deployment  across  an 
entire  complex  process 
may  take  2  to  5  years 

Scope 

Little  emphasis  on 
interrelationship  of 
business  processes  in  a 
business  system; 
internal  focus 

Coverage  of  many  sub¬ 
processes  and  “turf’; 
internal  focus 

Scope  is  entire  process 
or  major  sub-processes 
that  cover  broad  cross¬ 
functional  areas; 
includes  interfacing 
outside  the  organization 

Leadership 

Broad-based,  bottom-up 

Both  bottom-up  and  top- 
down,  more  senior 
leadership  needed 

Management  focused, 
top-down;  significant 
senior  management 
attention  and  time 

Means 

Generally,  improvement 
work  done  by  work  unit 
part-time  teams;  use  of 
quality  tools 

Improvement  work 
often  done  by 
diversified  task  forces  or 
teams  that  cross 
functions 

Improvement  generally 
done  by  dedicated  teams 
representing  end-to-end 
activities;  work 
facilitated  by  process 
sponsors  and  owners 

Performance  Gains 

Incremental:  Slightly 
increases  (5-10%) 
performance 

Moderately  increases 
performance 

Revolutionary:  Greatly 
increases  performance 

Costs,  Risks,  Pain 

Low:  Resources 
generally  easily  handled 
within  existing  budgets 
and  personnel 
allocations;  small 
iterative  investments; 
low-level  effort  offers 
few  risks;  pain  of 
implementation  is 
minimal 

Low  to  moderate: 
Resources  may  require 
shifting  funds  and 
personnel  or  adding 
more  funds  and 
personnel;  risks  increase 
somewhat  as  more 
activities  are  involved; 
implementation  pain 
covers  more  activities 

High:  Resources  require 
significant  funding  and 
dedicated  personnel 
allocations;  large, 
upfront  investment; 
risks  greatly  increase 
given  extensive  process 
coverage; 

implementation  pain  is 
high 

Table  2-1.  Process  Improvement  Approaches.  From  Caudle,  1995 


Business  process  redesign  can  be  viewed  as  either  a  subset  of  a  larger  business 
process  reengineering  effort  or  may  be  a  project  involving  a  single  process  in  an 
organization.  The  expectations  from  a  process  redesign  are  lower  than  those  associated 
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with  a  reengineering  effort,  as  the  changes  to  the  organization  are  not  as  great,  and  the 
structure  of  the  process  is  generally  accepted  in  its  current  state.  The  efforts  of  a  business 
process  redesign  usually  focus  on  removing  non-value  added  activities  and  reducing  the 
number  of  personnel  needed  to  perform  the  process  by  either  leveraging  technology,  or 
integrating  tasks  in  a  process.  (Caudle,  1995) 

Continuous  process  improvement  has  its  roots  in  the  Total  Quality  Management 
movement.  The  idea  is  to  constantly  improve  the  process  with  incremental  changes 
suggested  by  those  performing  the  process.  This  approach  is  decidedly  low  risk,  as  the 
types  of  changes  made  to  the  processes  usually  cost  little  to  implement  and  do  not  make 
‘revolutionary’  changes  to  the  process  or  organization.  (Caudle,  1995)  This  approach 
could  arguably  not  qualify  as  reengineering,  especially  in  the  eyes  of  Hammer  and 
Champy,  but  is  included  nevertheless  since  it  does  focus  on  improving  a  business 
process. 

The  redesign  of  the  PSC  process  addressed  in  this  thesis  qualifies  most  closely  as 
the  intermediate  approach  (i.e.,  business  process  redesign)  with  some  characteristics  of 
the  reengineering  approach.  Since  law  mandates  the  PSC  program,  the  process  cannot  be 
totally  redesigned  fi-om  a  “clean  sheet”  as  espoused  by  Hammer  and  Champy.  Rather, 
the  current  process  will  have  to  be  accepted  as  the  process  to  follow  to  reach  the  end  goal 
of  boarding  foreign  vessels.  This  does  not  mean,  however,  that  the  organizational 
structure  of  the  process  caimot  be  adjusted,  or  that  tasks  cannot  be  integrated.  It  is 
expected  that  the  use  of  technology  in  the  redesigned  process  will  be  a  key  enabler  to 
implementation  of  the  process. 

The  methodology  employed  for  the  PSC  process  redesign  is  one  introduced  by 
Mark  E.  Nissen  in  “Redesigning  Reengineering  through  Measurement-Driven  Inference”. 
This  methodology  is  a  “blend  of  expert  reengineering  methodologies”  (Nissen,  1998, 
p511)  and  uses  Knowledge  Based  Systems  technology  to  automate  part  of  the  redesign 
process.  The  general  redesign  process  is  depicted  in  Figure  2-1. 

The  first  step  is  to  identify  a  process  for  redesign.  Next,  the  process  is  modeled 
using  nodes,  directed  edges  and  process  attributes  to  facilitate  measurement. 


13 


Measurements  of  the  process  are  then  taken,  using  the  process  measures  shown  in  Table 
2-2.  From  the  measurements  taken,  specific  “pathologies”  are  identified,  and  then  used 
to  match  appropriate  redesign  transformations  for  the  process  redesign.  The  process  is 
then  redesigned  using  the  transformations  identified  in  the  previous  step,  usually  with 
more  than  one  redesign  candidate  generated.  Once  redesigned,  the  processes  are  tested, 
often  with  simulation,  and  finally  a  “preferred”  process  is  identified  for  implementation. 
(Nissen,  1998) 

For  this  research,  the  process  of  diagnosing  pathologies  and  matching 
transformations  is  performed  using  KOPeR,  the  “proof-of-concept  Knowledge  Based 
System”.  (Nissen,  1998)  This  gives  the  redesign  the  benefit  of  the  collective  knowledge 
gained  by  almost  a  decade  of  BPR. 

Simulation  of  the  current  and  redesigned  processes  is  carried  out  using  simulation 
models  built  in  the  simulation  software  package,  EXTEND+BPR®.  Parameters  for  the 
simulation  models  are  based  on  my  extensive  experience  of  supervising  the  PSC  program 
at  MSO/Group  Los  Angeles  -  Long  Beach,  California,  one  of  the  nations  largest  and 
busiest  port  complexes. 


Figure  2-2.  From  Nissen 
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Measure 

Graph-Based  Definition 

Process  Length 

Number  of  nodes  in  longest  path 

Process  Breadth 

Number  of  distinct  paths 

Process  Depth 

Number  of  process  levels 

Process  Size 

Number  of  nodes  in  process  model 

Process  Feedback 

Number  of  cycles  in  graph 

Parallelism 

Process  Size  divided  by  Length 

IT  Support 

Number  of  IT-support  attributes 

IT  Communication 

Number  of  IT-communication  attributes 

IT  Automation 

Number  of  IT-automation  attributes 

Organizational  Roles 

Number  of  unique  agent  role  attributes 

Process  Handoffs 

Number  of  inter-role  edges 

Organizations 

Number  of  imique  agent  organizational  attributes 

Value  Chains 

Niunber  of  imique  activity  Value  Chain  attributes 

Table  2-2.  FromNissen 


3.  Applicability  to  the  Port  State  Control  Process 

The  PSC  process  is  a  suitable  candidate  for  a  business  process  redesign.  It 
consists  of  a  multitude  of  tasks  performed  by  several  different  personnel  with  several 
redundant  steps  visible  to  even  those  unfamiliar  with  the  entire  process.  The  process  is 
well  defined  and  is  highly  repeatable;  two  important  attributes  for  performing  the 
redesign  methodology  as  described  by  Nissen. 

As  with  many  of  the  processes  performed  throughout  the  Coast  Guard,  the  PSC 
process  operates  with  little  information  technology  support.  The  information  technology 
support  used  by  the  process  is  a  legacy  database  running  on  antiquated  hardware.  The 
timing  is  right  to  leverage  the  Coast  Guard’s  investment  in  new  information  technology 
infrastructure  by  redesigning  processes  to  take  advantage  of  this  technology. 

Additionally,  the  redesign  of  the  PSC  process  is  consistent  with  the  US  Coast 
Guard  Information  Technology  Management  Strategy  vision  which  states:  “The  Coast 
Guard,  as  the  world’s  premier  maritime  service,  delivers  the  right  information  to  the  right 
people  at  the  right  time  to  support  all  Coast  Guard  Missions.”  (US  Coast  Guard 
Information  Technology  Management  Strategy,  1998) 
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III.  THE  PSC  PROCESS  MODEL 


A.  INTRODUCTION 

This  chapter  presents  the  model  of  the  current  PSC  process.  The  first  step  is  to 
decompose  the  process  into  major  sub  processes,  which  allows  for  finer  granularity  in 
taking  measurements  and  a  modular  approach  to  the  implementation  of  the  redesigned 
process.  A  graphical  process  model  is  created  for  each  sub  process  as  well  as  a  simulation 
model.  The  simulation  models  yield  baseline  process  cycle  time  measurements  and  are 
covered  in  depth  in  Chapter  IV.  Measurements  are  taken  from  the  graphical  model  and 
then  run  through  KOPeR,  which  helps  identify  transformations  for  each  sub  process.  The 
meaning  and  impacts  of  the  measurements  and  transformations  are  discussed.  Then 
based  on  these  transformations  potential  improvements  and  benefits  are  identified. 

The  current  process  can  be  decomposed  into  two  logical  segments  that  are  distinct 
in  their  purposes  and  outcomes:  the  targeting  process  and  the  vessel  boarding  process. 
The  targeting  process  starts  at  the  beginning  of  the  PSC  process,  proceeds  up  to,  and 
includes,  the  assignment  of  boarding  teams  to  the  selected  vessels.  The  boarding  process 
picks  up  where  the  targeting  process  leaves  off,  and  encompasses  the  remainder  of  the 
PSC  process. 

B.  TARGETING  PROCESS  MODEL 

This  section  discusses  the  targeting  process  model.  The  process  model  is 
described,  with  an  eye  toward  identifying  activity  inputs  and  outputs,  and  depicted  using 
a  graphical  method.  Improvements  and  benefits  to  the  process  are  then  discussed  later  in 
this  section.  Figure  3-1  is  a  graphical  depiction  of  the  current  targeting  process.  The 
activities  presented  in  Figure  3-1  are  used  to  guide  discussion  of  the  current  targeting 
process.  Each  activity  is  identified  by  a  node  number  and  is  connected  to  the  next  node 
with  a  directed  edge.  The  node  number  as  well  as  the  activity  name  are  identified  to 
provide  clarity  in  the  discussion  of  the  activity. 
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Activity  name 


Agent 


IT  Support 


V  y 


I 

To  vessel  boarding  process. 


Figure  3-1.  PSC  Targeting  Process 
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1.  Current  Process  Model 


The  targeting  process  starts  with  activity  node  one,  vessel  arrival  call  in.  A  vessel 
agent  calling  in  a  vessel  arrival  to  a  Coast  Guard  watchstander  accomplishes  this  activity. 
The  agent  provides  the  name  of  the  vessel,  the  berth  it  will  be  occupying,  the  date  of 
arrival,  the  official  number  of  the  vessel,  the  vessel’s  cargo,  and  the  agent’s  name  and 
agency. 

Activity  Node  two,  vessel  arrival  logged,  is  the  next  step.  In  this  activity,  the 
watchstander  logs  the  information  provided  by  the  agent.  The  PSC  section  personnel 
collect  the  log  twice  a  day,  once  in  the  morning  and  once  at  noon. 

Activity  node  three,  vessel  data  entry,  one  person  in  the  PSC  section  is  delegated 
to  enter  data  from  the  log  sheets  into  the  Coast  Guard  Marine  Safety  Information  System 
(MSIS).  The  user  inputs  the  information  from  the  vessel  arrival  log  into  a  computerized 
form.  When  the  data  is  submitted,  a  product  called  the  vessel  history  is  queued  up  to 
print  and  a  unique  case  number  is  created  for  each  vessel  input  to  the  system.  The  vessel 
history  contains  the  pertinent  data  on  the  vessel  as  well  as  all  Coast  Guard  contacts  on  the 
vessel. 

Activity  node  four,  vessel  grading,  the  grade  a  vessel  receives  is  based  on  its 
history  using  a  paper  matrix.  A  copy  of  the  matrix,  from  the  USCG  Marine  Safety 
Manual  (MSM)  Chapter  20,  is  included  as  Appendix  A  to  this  work.  The  matrix  is 
annotated  with  the  name  of  the  vessel,  official  number,  date  of  arrival,  berth,  and  the 
results  of  the  grading.  The  grade  a  vessel  receives  is  based  upon  the  number  of  points  the 
vessel  scores  on  the  criteria  supplied  on  the  matrix.  Based  upon  the  number  of  points 
scored  on  the  matrix,  the  vessel  is  assigned  a  priority  between  one  and  four,  with  one 
being  the  highest  priority. 

After  the  grading  is  complete,  activity  node  five,  the  logging  of  grading  results, 
occurs.  The  person  who  performed  the  grading  compiles  the  vessel  names  and  priorities 
into  a  log  that  houses  vessel  targeting  information  and  names.  The  grading  sheets  and 
histories  are  filed  by  the  date  the  vessels  are  due  to  arrive. 
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This  leads  into  activity  node  six,  review  of  grading.  A  supervisor  then  reviews 
each  grading  sheet  and  history  for  errors  and  makes  any  changes  needed  to  the  log  and 
the  histories.  If  the  quality  of  the  grading  sheets  is  not  up  to  the  supervisor  s 
expectations,  feed  back  is  provided  to  the  person  who  performed  the  activity  at  node  four. 
The  supervisor  also  is  empowered  to  downgrade  or  upgrade  the  priority  on  a  vessel 
during  the  review  based  on  a  set  of  rules  provided  in  the  MSM. 

Once  the  supervisor  makes  the  adjustments,  activity  node  seven,  boarding 
decisions  made,  begins.  Based  on  the  priority,  each  vessel  is  considered  for  a  boarding 
with  priority  one  vessels  always  being  boarded  and  priority  four  vessels  never  being 
boarded. 

After  the  supervisor  has  decided  on  the  vessels  to  board,  activity  node  eight, 
boarding  teams  dispatched,  is  the  final  node  to  occur.  The  supervisor  prioritizes  the 
vessels  targeted  for  boarding  based  on  the  number  of  personnel  available  for  the  day  and 
assigns  boarding  teams  to  each  vessel.  Each  boarding  team  is  provided  the  vessel  history 
and  grading  sheet  for  use  in  the  vessel  boarding  process. 

The  depiction  of  the  PSC  targeting  process  in  Figure  3-1,  in  addition  to  providing 
a  template  for  discussion,  is  also  suitable  for  taking  measurements  for  input  into  KOPeR. 
The  attributes  of  each  node  (e.g.,  process  name,  the  entity  performing  the  process,  and  the 
IT  resource  used  for  support)  describe  the  pertinent  measurement  items  present  at  the 
node.  The  measurements  for  the  process  that  KOPeR  needs  in  order  to  complete  a 
redesign  recommendation  are  shown  in  Table  3-1 .  (Nissen  1998) 


Configuration  Measure 


Value 


Process  Size 
Process  Length 
Handoffs 
Feedback  loops 
IT-Support 
IT-Commimication 
IT- Automation 


8 

8 

3 

1 

1 

0 

0 


Table  3-1 .  Measurements  for  the  PSC  Targeting  Process 


20 


Before  continuing,  it  is  important  to  imderstand  the  definitions  of  the  measures  of 
the  process.  Process  size  is  the  total  number  of  nodes  in  the  process  model,  in  this  case 
all  of  the  circles  in  the  graphical  model.  Process  length  is  the  number  of  nodes  in  the 
longest  path  in  the  process.  Handoffs  are  the  number  of  times  the  agent  role  changes  to  a 
different  role.  Feedback  loops  are  the  number  of  cycles  from  one  node  to  another  in  the 
opposite  direction  of  the  flow  in  the  graph.  IT-support  is  the  number  of  IT-siipport 
attributes.  IT-communication  is  the  number  of  IT-communication  attributes.  IT- 
automation  is  the  number  of  IT-automation  attributes.  (Nissen  1998,  p.513) 

These  measures  are  used  by  KOPeR  to  diagnose  the  pathologies  of  the  process 
and  then  give  recommended  transformations  based  on  those  pathologies.  KOPeR,  being 
a  “proof  of  concepf’  system,  is  obviously  limited  in  the  types  of  pathologies  and 
recommendations  it  can  give.  Therefore,  it  will  be  necessary  to  provide  additional 
manual  analysis  of  the  process  to  arrive  at  recommendations  with  suitable  detail  to 
perform  a  redesign  of  the  process. 

2.  Possible  Ways  to  Improve  the  Process 

Giving  the  process  measurements  in  Table  3-1  to  KOPeR  results  in  a  diagnosis 
and  a  list  of  recommendations.  The  diagnosis  provides  the  pathologies  that  were  detected 
from  the  measurements.  The  diagnostic  output  from  KOPeR  is  provided  in  Table  3-2.  To 
perform  this  diagnosis,  KOPeR  has  to  transform  the  measurements  given  into  a  fraction, 
which  allows  improved  interprocess  comparability  and  makes  the  system  more  robust  to 
variability  in  process  sizes.  These  fractions  are  arrived  at  by  dividing  the  process  size 
into  the  particular  measure  (example,  size  =  8,  handoffs  =  3,  3/8  =  0.375).  (Nissen  1998, 
p.531) 
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KOPeR  Diagnosis  for  the  Targeting  Process 


Measurements  (e.g.,  size  of  8)  suggest  the  small  PSC  Targeting 

process  suffers  from  the  following  pathologies: 

•  Parallelism  (1.0)-  sequential  process. 

•  Handoffs  fraction  (0.375)  -  process  friction. 

•  Feedback  fraction  (0. 1 25)  -  feedback  looks  OK. 

•  IT  support  fraction  (0.125)  -  inadequate  IT  support. 

•  IT  commxmication  fraction  (0.0)  -  inadequate  IT 
communications. 

•  IT  automation  fraction  (0.0)  -  IT  automation  first  requires 
substantial  infrastructure  in  terms  of  support  and 
communication. 

Table  3-2.  KOPeR  Diagnosis  (From  KOPeR  Web  Page) 

To  better  understand  the  diagnosis  and  the  recommendations  that  derive  from 
them,  it  is  helpful  to  understand  what  each  of  the  items  in  Table  3-2  means  and  the 
performance  implications  that  pertain  to  them. 

Parallelism  is  a  measure  of  how  linear  or  sequential  the  process  is,  with  a  measure 
of  1.00  being  the  minimum  value  for  this  measure.  It  is  arrived  at  by  dividing  the  process 
size  by  the  process  length.  The  diagnosis  for  this  measure  provided  by  KOPeR  is 
“sequential  process”.  This  is  based  solely  on  KOPeR  knowing  that  a  parallelism  value  of 
1 .00  is  the  minimum  value  for  the  measure.  As  stated  by  Nissen,  benchmarking  in  the 
domain  must  be  employed  to  determine  if  the  specific  level  of  parallelism  is  pathological. 
(Nissen  1998,  p.516)  In  the  case  of  the  PSC  targeting  process,  it  is  logical  to  infer  that  a 
parallelism  measure  of  1 .00  (the  minimum)  is  pathological  and  that  the  process  does  in 
fact  suffer  from  the  diagnosis  of  “sequential  process”. 

The  handoffs  fraction  is  a  measure  of  the  amount  of  job  specialization  and  the 
number  of  times  the  process  is  fragmented  into  smaller  pieces.  For  the  targeting  process, 
KOPeR  has  given  the  pathology  of  “process  fiiction”.  This  equates  to  an  amoimt  of 
friction  in  the  process  and  the  related  delays  or  increases  in  cycle  time  in  the  process. 
The  fraction  is  computed  by  dividing  the  handoffs  measure  by  the  size  of  the  process. 
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The  implications  of  a  handoffs  fraction  greater  than  zero  are  attendant  delays  in  the 
system  due  to  inefficiencies  in  the  way  the  work  flow  is  laid  out  or  the  way  it  is 
completed 

The  feedback  fraction  is  a  measure  of  the  amount  of  reviews  in  the  process.  For 
the  targeting  process,  KOPeR  has  given  an  “OK”  for  the  pathology.  The  fraction  is 
calculated  by  dividing  the  feedback  measure  by  the  process  size.  This  measure  is  one 
that  would  indicate  lost  time  in  the  process  due  to  excessive  reviews,  not  empowering 
personnel  to  make  decisions,  or  a  centralized  control  figure  in  the  process.  This  is 
another  area  that  can  increase  cycle  time  in  a  process. 

The  IT  support  fraction  is  a  measure  of  the  amount  of  information  technology 
support  in  the  process.  It  is  calculated  by  dividing  the  IT-support  measure  by  the  process 
size.  For  the  targeting  process,  KOPeR  gave  a  pathology  of  “inadequate  IT-support”. 
This  would  point  to  a  process  where  all  of  the  processes  are  done  manually,  and  there  is 
little  to  no  use  of  modem  information  technology  tools.  This  measure  also  takes  in  part 
of  the  IT  infrastructure  provided  to  support  the  process,  the  other  part  of  the  infrastructure 
is  covered  under  IT  communication. 

The  IT  communication  fraction  is  a  measure  of  the  use  of  information  technology 
to  provide  inter  activity  communication  in  the  process.  For  the  targeting  process,  KOPeR 
provided  a  pathology  of  “inadequate  IT  communications”.  This  measure,  like  the  others, 
is  calculated  by  dividing  the  IT-communications  measure  by  the  process  size.  Using 
more  information  technology  to  assist  with  inter  activity  commimication  would  speed  the 
process  and  lower  process  cycle  time.  Examples  of  IT-communication  would  be  email, 
shared  databases  or  workflow  systems. 

The  IT-automation  fraction  is  a  measure  of  the  usage  of  information  technology  to 
provide  automation  within  the  process.  The  pathology  provided  by  KOPeR,  for  the 
targeting  process,  was  that  “IT  automation  first  requires  substantial  infrastmcture  in  terms 
of  support  and  communications”.  While  cryptic  at  first,  it  does  make  sense  when  looking 
at  the  pathologies  identified  for  IT  communications  and  support.  If  there  is  little  in  the 
way  of  IT  communications  or  support  it  follows  naturally  that  automation  is  a  ways  down 
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the  road.  Automation  would  involve  the  use  of  IT  support  and  communications  to  further 
automate  activities  in  the  process.  Automation  could  take  the  form  of  intelligent  software 
agents  performing  the  process  on  their  own  or  could  be  as  simple  as  a  piece  of  code  that 
transforms  data  input  to  a  usable  output. 

KOPeR  then  provides  a  set  of  recommendations  for  transformations  to  the  process 
based  on  the  pathologies  identified  above.  These  recommendations  are  contained  in 
Table  3-3. 

The  recommendations  from  KOPeR  are  generic  and  require  the  application  of 
specifics  to  complete  the  process  redesign.  Examination  of  the  process  in  light  of  each 
recommendation  will  bring  out  some  ways  of  redesigning  the  process  to  improve 
performance. 


24 


KOPeR  Recommendations  for  the  Targeting  Process 


De-linearize  process  activities  to  increase  parallelism;  such  activities 
must  be  sequentially  independent  (e.g.,  have  mutually  exclusive  inputs  and 
outputs). 

Try  a  case  manager  or  case  team  to  decrease  friction;  be  sure  to  include  a 
source  of  expertise. 

Look  to  information  technology  to  increase  support  to  process  activities; 
decision  support  systems  and  desktop  office  tools  generally  have  good 
payoffs  and  intelligent  systems  can  greatly  enhance  knowledge  work;  be 
sure  to  address  personnel  training  and  maintenance  of  the  IT. 

Look  to  information  technology  to  increase  support  to  process 
communications;  e-mail  and  shared  databases  through  local/wide  area 
networks  generally  have  good  payoffs  and  worhflow  systems  can  greatly 
expedite  process  flows;  be  sure  to  address  personnel  training  and 
maintenance  of  the  IT. 

Look  to  information  technology  to  automate  process  activities,  but  note 
that  substantial  IT  infrastructure  is  first  required,  particularly  in  terms  of 
process  support  and  communication;  try  worlflow  systems  for  support  and 
communication,  and  then  look  to  intelligent  agents,  which  can  enable 
many  electronic  commerce  opportunities. 

In  addition  to  delinearization  and  the  use  of  a  case  manager,  workflow 
systems  offer  good  potential  for  process  improvement;  this  requires 
substantial  IT  infrastructure  and  support  however. 


Table  3-3.  KOPeR  Recommendations  (Output  from  KOPeR  Web  Page) 

Delinearizing  the  process  may  be  a  viable  alternative;  but  each  process  activity  is 
not  sequentially  independent.  To  illustrate  this  the  process  will  be  examined  by 
following  one  vessel  arrival  from  the  beginning  to  the  end  of  the  process.  Activity  node 
numbers  are  taken  from  Figure  3-1.  All  nodes  are  contingent  upon  the  previous  node 
when  addressing  one  vessel  in  the  system.  When  there  are  multiple  vessels  in  the  system, 
certain  nodes  can  be  completed  concurrently  for  different  vessels  in  the  system  (e.g., 
node  four  and  node  six  activities  can  be  completed  at  the  same  time  but  on  different 
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vessels).  At  node  one,  the  vessel  arrival  is  called  in  to  node  two  where  it  is  logged  into 
the  arrival  log.  Node  three  requires  the  information  from  node  two  to  perform  the  task  of 
vessel  data  entry  to  MSIS.  Node  four  requires  the  vessel  history  from  MSIS  to  grade  the 
vessel.  Node  five  requires  the  results  from  node  four  to  log  the  results  of  the  grading. 
Node  six  needs  to  have  completed  vessel  grading  sheets  and  a  completed  vessel  log  to 
perform  the  review.  Node  seven  requires  the  output  from  node  six  to  make  a  decision  on 
which  vessels  to  board.  Finally,  node  eight  requires  that  the  boarding  decisions  be  made 
before  assigning  a  team  to  a  vessel  to  be  boarded.  At  any  node,  if  the  information  is  not 
available  from  the  previous  one,  the  activity  of  that  node  cannot  be  completed.  It  is 
possible  to  process  each  vessel  arrival  in  parallel  up  to  the  point  of  node  seven  (making 
the  decision  on  which  vessels  to  board).  This  could  be  done  by  completely  automating 
the  activities  from  nodes  one  through  six  and  allowing  identical  multiple  processes  to  run 
in  parallel  up  to  the  collection  point  of  node  seven.  The  bottleneck  in  the  process  would 
then  be  node  seven,  as  it  would  need  all  of  the  inputs  from  the  parallel  processes  to 
perform  the  boarding  decision  task. 

Next  is  the  case  manager.  A  case  manager  is  defined  as  a  person  who  performs 
the  majority  of  the  activities  in  the  process.  The  case  manager  would  act  as  a  single  point 
of  contact  for  the  process  and  perform  the  process  from  beginning  to  the  end.  This 
eliminates  the  fragmentation  of  the  process  and  provides  continuity  of  thought  and  action 
through  out  the  process.  Implementing  a  case  manager  without  performing  any  other 
intervention  would  likely  be  a  mistake.  If  just  a  case  manager  were  implemented,  the 
majority  of  the  process  would  fall  on  that  one  person’s  shoulders.  The  case  manager 
could  potentially  perform  all  of  the  activities  in  the  process  except  for  node  one,  calling 
in  a  vessel  arrival. 

Having  attempted  to  implement  just  such  a  system  myself,  it  quickly  became 
apparent  that  the  reliance  on  one  person’s  expertise  to  perform  the  entire  process  was 
imacceptable.  The  person  performing  the  case  manager  role  builds  up  a  local  knowledge 
of  the  process,  has  learned  all  of  the  rules  for  the  process  and  knows  what  shortcuts  are 
allowable  and  acceptable  in  the  system.  Additionally,  when  the  entire  process  is 
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performed  by  one  person,  the  other  personnel  in  the  office  look  at  that  one  person  as 
being  the  “expert”  and  subsequently  refer  all  questions  in  that  subject  matter  to  the 
“expert”.  Due  to  other  operational  programs,  training,  etc.  they  ignore  the  workings  of 
the  process  and  consequently  do  not  have  a  working  knowledge  of  the  process  when  there 
is  a  designated  expert.  This  leads  to  a  rush  to  the  manuals  to  learn  the  workings  of  the 
process  when  the  “expert”  is  not  present  and  errors  are  made  that  the  “expert”  would  not 
have  made.  To  continue  my  story,  losing  that  one  person  led  to  confusion  and  multiple 
errors  that  then  had  to  be  sorted  out  at  a  higher  level  increasing  the  amount  of  time  it  took 
to  dispatch  boarding  teams.  Not  only  was  there  lost  time,  but  the  unit  missed  boarding  a 
few  high  priority  vessels  due  to  the  confusion  and  time  it  took  to  sort  things  out.  Missing 
high  priority  vessel  boardings  is  not  something  that  was  smiled  upon  by  the  Commanding 
Officer  or  his  superiors.  It  was  found  through  this  experiment  that  having  the  ability  to 
break  down  the  responsibilities  led  to  a  more  robust  process  when  faced  with  multiple 
personnel  absences,  which  were  quite  frequent  due  to  the  pull  of  other  operational 
commitments.  Therefore,  a  case  manager  could  be  implemented  only  if  the  majority  of 
the  process  is  automated,  as  the  reliance  on  one  person  is  unacceptable  as  discussed 
above. 

Information  technology  is  an  area  where  the  current  process  is  particularly 
lacking.  As  seen  with  the  IT  related  diagnoses  from  KOPeR,  and  a  general  perusal  of  the 
process  description,  the  only  IT  related  support  provided  to  the  process  is  a  database 
system.  While  MSIS  was  state  of  the  art  at  one  point  in  time,  it  is  currently  unable  to 
provide  the  type  of  service  (e.g.,  100%  uptime)  required  by  the  PSC  process  and  is  at 
times  highly  unreliable.  As  an  example,  one  month  due  to  equipment  problems,  MSIS 
was  not  available  for  almost  an  entire  week.  Without  MSIS,  the  PSC  process  quickly 
became  a  guessing  game  on  which  vessels  to  board  as  the  vessel  histories  were  not 
available. 

Regarding  IT  support,  as  stated  above,  MSIS  is  the  only  IT  support  provided  to 
the  current  process.  However,  the  replacement  for  MSIS,  the  Marine  Safety  Network 
(MSN),  is  currently  being  developed.  MSN  is  a  relational  database/application  that  will 


27 


keep  track  of  all  vessel-related  processes  in  the  Coast  Guard.  It  is  designed  to  be 
accessed  via  the  Internet  from  multiple  locations.  MSN  can  provide  IT  support  to  the 
process  by  supporting  all  of  the  process  activities  via  use  of  an  electronic  repository  of 
information  which  is  easily  accessible  from  any  computer  terminal  in  the  Coast  Guard 
using  a  web  type  interface.  Other  areas  where  MSN  could  provide  IT  support  in 
conjunction  with  human  labor  are  the  grading  of  vessels  (activity  node  four  Figure  3-1) 
and  the  decision  making  process  of  deciding  on  which  vessels  to  board  (activity  node 
seven  Figure  3-1). 

IT  support  and  IT  communication  are  closely  related,  though  separate.  In  order  to 
provide  IT  communications,  a  support  function  is  required  to  hold  the  information  that 
the  communications  function  is  providing.  IT  communication  is  also  completely  lacking 
in  the  current  process.  IT  communication  can  be  provided  to  the  process  with  MSN  just 
as  IT  support  could  be  provided.  IT  commimication  would  take  the  form  of  automating 
the  keeping  of  lists  of  vessels  (e.g.,  vessel  arrivals,  vessels  targeted  for  boarding  etc.) 
which  could  then  be  viewed  by  personnel  associated  with  the  process.  This  would 
eliminate  the  paper  logs,  and  the  passing  of  paper  grading  sheets  and  vessel  histories. 

With  IT  automation,  there  is  a  caveat  that  substantial  infrastructure  in  terms  of 
support  and  communication  need  to  be  made  before  automation  can  be  put  in  place.  As 
mentioned  above,  adding  functionality  to  MSN  can  provide  the  required  support  and 
communication  needed  to  provide  additional  automation  to  the  process. 

IT  automation  is  concerned  with  removing  the  need  for  human  labor  in  the 
process  and  having  a  computer  perform  the  activities  in  the  process.  Extending  the  use  of 
MSN  a  little  further,  the  entire  process,  from  the  agent  call  in  (activity  node  one)  to  the 
selection  of  vessels  to  board  (activity  node  seven),  could  be  automated.  There  would  still 
be  some  related  support  and  commimication  attributes  to  such  a  system,  but  the  removal 
of  human  labor  in  most  of  the  activities  of  the  process  would  obviate  the  need  for  many 
of  those  attributes.  Some  specific  ideas  where  IT  automation  could  be  applied  are: 

1.  An  application  or  module  to  MSN  could  be  built  that  automatically  scores 
vessels  when  the  arrival  is  entered  into  the  system. 
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2.  A  decision  support/expert  system  consisting  of  rules  developed  from 
information  mined  from  the  database  could  be  developed  that  assists  in 
determining  which  vessels  to  board. 

Additionally,  utilizing  IT  automation  would  fill  the  gap  needed  to  successfully  implement 
the  case  manager  as  well  as  parallel  processes  as  discussed  above.  IT  automation  is  an 
area  where  I  see  the  most  pay  off  in  the  redesign  of  this  process. 

In  addition  to  MSN,  the  Coast  Guard  has  recently  completed  roll  out  of  Coast 
Guard  Standard  Workstation  III  (CGSWIII).  CGSWIII  is  a  commercial  off  the  shelf 
technology  solution,  which  mirrors  the  IT-21  requirements  of  the  Navy.  It  consists  of  a 
networked  Windows  NT  operating  system,  operating  on  standard  PC  hardware.  Each 
workstation  has  a  standard  system  image  (software  and  configuration),  and  has  the  ability 
to  connect  to  the  Coast  Guard  Intranet  (CGWEB)  as  well  as  the  Internet. 

Leveraging  the  investment  of  CGWSIII  and  MSN  to  provide  all  IT  attributes  to 
the  PSC  process,  as  discussed  above,  appears  to  be  the  best  way  to  proceed.  There  are 
some  limiting  factors  to  this  such  as  no  choice  of  hardware  architecture,  and  the  ways 
technologies  could  be  used.  For  instance,  since  there  is  already  a  centralized  database 
(MSN)  in  place,  the  use  of  client/server  architecture  has  already  been  predetermined. 
Regarding  the  limitations  of  technology,  the  use  of  a  local  workflow  system  would  not 
make  sense  due  to  the  centralized  database  and  client/server  architecture. 

To  summarize  this  section,  I  will  present  a  look  at  the  redesigned  process  in 
diagnosis  form.  To  delinearize  the  process,  the  activities  of  the  process  from  the  agent 
call  in  to  the  selection  of  vessels  to  board  (activity  nodes  one  through  six)  have  been 
automated,  which  allows  several  of  these  processes  to  operate  in  parallel. 

A  case  manager  is  implemented  reducing  hand  off  friction.  This  is  due  to  the 
automation  of  the  call  in  and  grading  process.  The  duties  of  the  case  manager  now 
consist  of  selecting  the  vessels  to  board  (with  assistance  from  the  decision  support 
system)  and  assigning  boarding  teams  to  vessels.  IT  support  is  provided  in  the  form  of 
MSN  keeping  the  information  regarding  vessel  arrivals  and  vessel  grading  information. 
IT  communication  is  provided  by  MSN  through  the  CGWEB  giving  access  to  the  vessel 
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lists.  Finally,  IT  automation  is  provided  by  automating  the  process  and  providing 
decision  support  to  the  case  manager. 

3.  Benefits  from  Improving  the  Process 

There  are  some  benefits  from  improving  this  process.  Only  the  measurable  ones 
will  be  addressed  here,  as  some  of  the  other  benefits  obtained  by  improving  the  process 
may  not  be  discovered  due  to  their  intangibility.  For  example,  an  improvement  in  morale 
that  leads  to  better  recruiting  for  the  Coast  Guard.  Most  of  the  benefits  derive  from  the 
use  of  IT  automation;  however,  there  are  some  benefits  deriving  from  the  other  diagnosis 
categories,  but  there  are  not  as  many  due  to  IT  automation  being  the  primary  enabler  of 
this  process  redesign.  I  will  begin  with  those  categories  that  have  the  least  number  of 
benefits  and  finish  with  IT  automation  which  has  the  most  benefits. 

A  benefit  gained  from  delinearizing  the  process  would  be  a  reduction  in  cycle 
time  due  to  the  addition  of  the  automation,  and  the  ability  to  process  multiple  vessel 
arrivals  at  one  time. 

A  benefit  gained  from  implementing  a  case  manager  would  be  the  reduction  of 
personnel  from  the  process.  Implementing  a  case  manager  would  remove  the  personnel 
required  for  activity  nodes  two  through  five  in  Figure  3-1.  These  savings  would  be  two 
people,  the  watchstander  and  the  petty  officer. 

Replacing  MSIS  with  MSN  and  adding  additional  IT  support  from  MSN  to  the 
process  would  yield  increased  benefits  by  leveraging  the  investments  of  MSN  and 
CGSWIII  to  a  greater  degree.  Another  benefit  of  IT  support  is  that  it  is  a  key  enabler  of 
implementing  the  automation  of  the  process.  Without  the  IT  support  provided  by  MSN, 
the  automation  of  the  process  would  be  more  expensive  to  implement  because  a  support 
mechanism  (a  distributed  database)  would  have  to  be  provided  in  addition  to  the 
automation  itself 

A  benefit  of  IT  communication  is  that  it  is  the  second  enabler  to  IT  automation.  IT 
communication  allows  automation  to  work  more  effectively  because  it  eliminates  the 
passing  of  paper.  For  example,  eliminating  vessel  logs  and  grading  sheets  and  letting 
automation  electronically  access  all  of  the  information  contained  in  the  logs.  Another 
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benefit  is  that  vessel  information  is  readily  available  to  everyone  needing  it  as  opposed  to 
one  centralized  place  where  only  a  few  have  access  to  it. 

The  benefits  of  IT  automation  are: 

1.  Automating  a  large  portion  of  the  process,  if  not  all  of  it,  results  in  removing 
an  administrative  burden  from  at  least  two  personnel  in  the  process,  the 
supervisor  and  the  person  assigned  to  perform  the  vessel  grading.  This  would 
also  allow  the  implementation  of  a  case  manager. 

2.  Automating  the  grading  of  the  vessels  would  remove  this  repetitive  activity 
from  human  hands.  The  grading  activity  occurs  for  every  vessel  arrival  at  a 
port,  for  example,  if  there  are  20  vessel  arrivals  a  day  one  person  has  to  print 
out  histories  and  grade  20  vessels.  Performing  this  task,  day  in  and  day  out, 
365  days  a  year,  is  a  repetitive  task  best  left  to  a  computer.  Assuming  the 
automated  grading  process  was  implemented  correctly,  the  supervisor  would 
not  have  to  review  the  grading  results  as  closely  as  they  would  be  correct 
every  time.  This  would  free  the  supervisor  and  person  assigned  to  do  the 
grading  to  perform  other  duties  not  related  to  the  process.  Therefore,  the  use 
of  automation  for  this  process  would  reduce  rework  and  review  time  for  the 
supervisor,  as  the  information  provided  by  the  automated  system  would  be 
more  accurate  and  consistent. 

3.  Consistency  in  the  application  of  the  process  throughout  the  Coast  Guard 
would  also  improve  with  the  automation  of  the  process,  as  I  will  describe. 
With  all  units  in  the  Coast  Guard  using  the  same  system  to  process  vessel 
arrivals  from  the  beginning  to  the  end  of  the  process,  there  would  be  no 
ambiguity  in  the  application  of  the  business  rules.  Each  vessel  targeting 
process  at  each  unit  would  be  performed  consistently  as  they  would  all  be 
running  off  the  same  server  running  the  same  software.  Therefore,  a  vessel 
that  scores  a  priority  one  in  Seattle  would  score  as  a  priority  one  in  Los 
Angeles  as  well.  This  is  different  from  the  current  system  as  some  MSOs 
score  vessels  differently. 
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4.  Feedback  to  vessel  agents  and  the  vessels  they  represent  would  improve 
because  when  the  targeting  process  is  automated,  the  grading  process  would 
already  be  complete  when  the  personnel  come  to  work  in  the  morning.  The 
system  will  already  have  a  list  of  suggested  vessels  to  board  for  the 
supervisor,  and  the  vessel  agent  can  be  notified  his  vessel  is  going  to  be 
boarded  before  he  has  his  coffee  in  the  morning.  With  this  improvement  in 
the  availability  of  information,  there  will  be  a  reduction  in  the  process  cycle 
time  as  shown  above. 

C.  VESSEL  BOARDING  PROCESS  MODEL 

This  section  discusses  the  vessel  boarding  process  model.  The  process  model  is 
described,  with  an  eye  toward  identifying  activity  inputs  and  outputs,  and  depicted  using 
a  graphical  method.  Improvements  and  benefits  to  the  process  are  then  discussed  later  in 
this  section.  Figure  3-2  is  a  graphical  depiction  of  the  current  targeting  process.  As  I  did 
in  Section  B,  I  will  use  the  activities  presented  in  Figure  3-2  to  guide  my  discussion  of 
the  current  vessel  boarding  process.  Each  activity  is  identified  by  a  node  number  and  is 
connected  to  the  next  node  with  a  directed  edge.  In  my  discussion,  I  will  identify  the  node 
number  as  well  as  the  activity  name  to  provide  clarity  in  the  discussion  of  the  activity. 
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1.  Current  Process  Model 


This  process  starts  at  activity  node  nine,  document  check.  The  boarding  teams  are 
given  the  histories  and  completed  grading  sheets  for  the  vessels  assigned  to  the  team.  On 
board  the  vessel,  the  team  uses  a  paper  based  boarding  book  to  document  the  vessel 
boarding.  Information  regarding  the  vessel  such  as  name,  official  number,  date,  and  other 
information  are  hand  copied  fi-om  the  vessel  history  to  the  boarding  book.  The  boarding 
officer  reviews  the  vessel’s  papers  and  compares  the  information  contained  on  them  to 
the  vessel  history.  These  papers  are  documentation,  firom  the  Flag  State  of  the  vessel, 
that  the  vessel  has  undergone  the  required  safety  and  structural  surveys  called  for  by 
International  treaties  and  laws  as  well  as  other  physical  description  papers  of  the  vessel. 
The  primary  information  provided  by  these  documents  are  issue  dates,  expiration  dates, 
endorsement  dates,  and  the  entity  issuing  the  document.  Any  changes  to  the  information 
are  recorded  in  the  boarding  book  for  the  vessel.  The  vessel  paperwork  review  is  usually 
accomplished  prior  to  any  physical  inspection  of  the  vessel;  this  is  to  ensure  the  vessel 
actually  needs  a  boarding  and  to  give  the  vessel  Master  time  to  get  the  crew  members 
ready  to  assist  the  boarding  team. 

Activity  node  ten,  physical  inspection.  After  the  paperwork  review,  the  physical 
inspection  of  the  vessel  is  conducted,  and  the  various  inspection  actions  are  initialed  by 
the  boarding  officer  signifying  completion  of  the  item(s). 

Activity  node  11,  boarding  complete.  At  the  end  of  the  physical  inspection,  any 
discrepancies  found  are  transcribed  from  the  boarding  book  onto  a  vessel  boarding  letter. 
The  vessel  boarding  letter  contains,  in  addition  to  any  discrepancies,  the  identifying 
information  on  the  vessel,  the  date  of  the  boarding,  and  the  signatures  of  the  boarding 
officer  and  vessel  Master.  This  letter  is  left  on  board  the  vessel  as  an  official  record  of 
the  results  of  the  boarding.  If  there  are  any  discrepancies  such  that  the  vessel  would 
endanger  the  personnel  on  board  or  the  environment,  the  vessel  is  held  in  port  until  the 
items  are  repaired.  If  this  is  the  case,  several  other  paper  documents  have  to  be  prepared 
to  hold  the  vessel  and  notify  the  chain  of  command  about  the  detention.  This  paper  work 
is  usually  done  after  the  boarding  team  returns  to  the  office.  The  letter(s)  requires  the 
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signature  of  the  Commanding  Officer  of  the  MSO  and  an  additional  trip  to  the  vessel  to 
deliver  the  official  letter,  which  holds  the  vessel  in  port. 

Activity  node  12,  data  input.  After  leaving  the  vessel,  the  boarding  officer 
prepares  the  paperwork  documenting  the  boarding.  The  boarding  book  is  checked  for 
completeness,  which  consists  of  ensuring  all  items  are  initialed,  all  blanks  are  filled  out, 
and  all  personnel  in  the  boarding  party  have  signed  the  boarding  book.  MSIS  is  then 
updated  through  the  case  number  for  the  boarding.  Any  changes  to  vessel  information 
are  updated  and  a  narrative  of  what  was  done  on  the  vessel  is  completed.  The  updated 
information  is  printed  out  in  hard  copy  form  for  inclusion  with  the  boarding 
documentation. 

Activity  node  13,  boarding  documentation  put  together.  The  print  outs,  the 
boarding  book,  a  copy  of  the  boarding  letter,  and  the  detention  paperwork,  if  the  vessel 
was  detained,  is  then  compiled  and  submitted  for  review  by  a  supervisor. 

Activity  node  14,  boarding  case  reviewed.  The  supervisor  reviews  the  boarding 
case  and  if  any  discrepancies  in  the  paperwork  are  identified,  they  are  noted  and  returned 
to  the  boarding  officer  for  rework. 

Activity  node  15,  boarding  case  filed.  After  final  approval  of  the  package,  it  is 
filed  locally  at  the  MSO.  Then  the  case  in  MSIS  is  “validated”,  meaning  that  it  is  closed 
and  further  alterations  to  the  record  are  not  allowed. 

Activity  node  16,  log  vessel  no  boards.  Finishing  the  process,  vessels  not  targeted 
for  boarding  are  tracked  on  when  they  leave  the  port.  After  a  vessel  departs,  an  entry  is 
made  in  MSIS  via  the  case  number  for  the  port  call  of  the  vessel.  This  closes  the  case  in 
MSIS  and  provides  documentation  that  the  vessel  made  a  port  call,  but  was  not  boarded. 

The  depiction  of  the  PSC  vessel  boarding  process  in  Figure  3-2,  in  addition  to 
providing  a  template  for  discussion,  is  also  suitable  for  taking  measurements  for  input 
into  KOPeR.  The  attributes  and  other  features  are  the  same  as  presented  in  Section  B. 
The  measurements  for  the  process  that  KOPeR  needs  in  order  to  complete  a  redesign 
recommendation  are  shown  in  Table  3-4.  The  definitions  and  implications  of  the 
measurements  are  the  same  as  those  described  previously  for  the  targeting  process. 
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Configuration  Measure 

Value 

Process  Size 

8 

Process  Length 

8 

Handoffs 

3 

Feedback  loops 

1 

IT-Support 

2 

IT -Communication 

0 

IT- Automation 

0 

Table  3-4.  Measurements  for  the  PSC  Vessel  Boarding  Process 


2.  Possible  Ways  to  Improve  the  Process 

Giving  the  process  measurements  in  Table  3-4  to  KOPeR  results  in  a  diagnosis 
and  a  list  of  recommendations.  As  seen  with  the  targeting  process,  the  diagnosis  provides 
the  pathologies  that  were  detected  from  the  measurements.  The  diagnostic  output  from 
KOPeR  is  provided  in  Table  3-5. 


_ KOPeR  Diagnosis  for  the  Vessel  Boarding  Process  _ 

Measurements  (e.g.,  size  of  8)  suggest  the  small  Vessel  Boarding  Process 
suffers  from  the  following  pathologies: 

•  {1.0) -sequential process. 

•  Handoffs  fraction  (0.375)  -  process  friction. 

•  Feedback  fraction  (0. 125)  -  feedback  looks  OK. 

•  IT  support  fraction  (0.25)  -  inadequate  IT  support. 

•  IT  conummication  fraction  (0.0)  -  inadequate  IT  communications. 

•  IT  automation  fraction  (0.0)  -  IT  automation  first  requires  substantial 
infrastructure  in  terms  of  support  and  communication. 


Table  3-5.  KOPeR  Diagnosis  (From  KOPeR  Web  Page) 

Inspection  of  the  diagnosis  shows  the  pathologies  identified  are  very  similar  to 
those  found  for  the  targeting  process.  The  measures,  how  the  niunbers  are  calculated, 
and  the  performance  implications  are  the  same  as  those  discussed  previously  in  Section  B 
for  the  targeting  process. 
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Again,  as  seen  in  Section  B,  KOPeR  then  provides  a  set  of  recommendations  for 
transformations  to  the  process  based  on  the  pathologies  identified  above.  These 
recommendations  are  contained  in  Table  3-6. 


KOPeR  Recommendations  for  the  Vessel  Boarding  Process 


Delinearize  process  activities  to  increase  parallelism;  such  activities  must 
be  sequentially  independent  (e.g.,  have  mutually-exclusive  inputs  and 
outputs). 

Try  a  case  manager  or  case  team  to  decrease  friction;  be  sure  to  include  a 
source  of  expertise. 

Look  to  information  technology  to  increase  support  to  process  activities; 
decision  support  systems  and  desktop  office  tools  generally  have  good 
payoffs  and  intelligent  systems  can  greatly  enhance  knowledge  work;  be 
sure  to  address  personnel  training  and  maintenance  of  the  IT. 

Look  to  information  technology  to  increase  support  to  process 
communications;  e-mail  and  shared  databases  through  local/wide  area 
networks  generally  have  good  payoffs  and  workflow  systems  can  greatly 
expedite  process  flows;  be  sure  to  address  personnel  training  and 
maintenance  of  the  IT. 

Look  to  information  technology  to  automate  process  activities,  but  note 
that  substantial  IT  infrastructure  is  first  required,  particularly  in  terms  of 
process  support  and  communication;  try  worlflow  systems  for  support  and 
communication,  and  then  look  to  intelligent  agents,  which  can  enable 
many  electronic  commerce  opportunities. 

In  addition  to  delinearization  and  the  use  of  a  case  manager,  worlflow 
systems  offer  good  potential  for  process  improvement;  this  requires 
substantial  IT  infrastructure  and  support  however. 


Table  3-6.  KOPeR  Recommendations  (From  KOPeR  Web  Page) 

As  stated  in  Section  B,  the  results  from  KOPeR  are  generic  and  need  to  be 
specific  to  complete  the  redesign.  The  recommendations  are  markedly  similar  to  those  of 
the  targeting  process;  this  is  not  surprising  as  the  pathologies  found  for  both  processes 
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were  identical.  Examination  of  the  process  in  light  of  each  recommendation  will  bring 
out  some  ways  of  redesigning  the  process  to  improve  performance. 

Proceeding  in  the  same  fashion  as  in  Section  B,  the  inputs  and  outputs  of  each 
activity  node  will  be  examined  to  determine  if  the  activities  are  sequentially  independent. 
Node  numbers  are  taken  from  Figure  3-2.  The  process  begins  with  node  «me-the 
document  check.  Regarding  its  input,  there  is  the  vessel  history,  and  the  output  there  is 
the  boarding  book  entries  resulting  from  the  docmnent  check.  Node  ten-ihe  physical 
inspection  of  the  vessel.  Here  the  boarding  book  is  used,  but  is  not  necessary  for  the 
activity  to  begin.  Node  11  requires  the  inputs  from  nodes  nine  and  ten  to  complete  the 
boarding.  Node  12  requires  the  output  from  node  11  and  has  as  its  output  the  raw 
materials  for  the  next  activity  at  node  13.  Node  13  requires  the  raw  materials  from  node 
12  to  complete  the  boarding  package  and  pass  it  on  to  the  supervisor  for  review  in  node 
14.  The  supervisor  needs  to  have  a  package  to  review  at  node  14,  and  node  15  needs  the 
approved  package  to  complete  the  filing  process.  Finally,  node  75— logging  vessel  no 
boards,  does  not  rely  on  any  of  the  nodes  in  this  process  and  arguably  could  be  a  separate 
process  in  itself  The  input  to  node  16  is  a  vessel  departure  notice.  This  activity  was 
included  in  this  particular  process  as  the  practice  in  the  field  is  to  update  MSIS  items  in 
batches  due  to  the  slow  speed  and  the  availability  of  computer  terminals.  This  task, 
referred  to  as  “feeding  the  green  eyed  monster”  (due  to  the  monochrome  green  monitor), 
is  particularly  dreaded  by  marine  safety  personnel  due  to  the  monotonous  nature  of  the 
task.  When  the  finished  boarding  cases  are  validated  in  MSIS,  the  vessels  not  boarded, 
which  have  departed  the  port,  are  updated  at  the  same  time. 

For  the  process,  the  only  two  nodes  that  could  run  in  parallel  are  nodes  nine  and 
ten.  This  is  because  it  is  not  necessary  to  complete  the  document  check  before  begiiming 
the  physical  inspection  of  the  vessel.  However,  some  additional  background  on  the 
process  is  necessary  to  understand  why  the  document  check  (node  nine)  and  the  physical 
inspection  (node  ten)  are  sequentially  positioned.  In  the  International  treaties,  a  portion 
states  that  parties  to  the  convention  will  accept  the  attestation  of  the  Flag  State  that  the 
vessel  complies.  Due  to  the  shabby  state  of  some  vessels  entering  US  waters,  the  Coast 
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Guard  extended  this  to  include  a  physical  examination  to  verify  the  attestation  of  the  Flag 
State.  To  give  the  boarding  officers  a  better  feel  of  some  of  the  areas  to  concentrate  on 
during  the  physical  inspection,  the  document  examination  is  done  first.  The  document 
check  activity  also  gives  the  boarding  officer  a  feel  for  how  well  the  crew  interacts  with 
each  other  and  provides  time  to  explain  to  the  Master  the  procedures  of  the  examination. 
The  time  saved  in  making  the  activities  parallel  would  not  offset  the  information  gained 
by  leaving  the  activities  serial.  For  these  reasons,  I  do  not  recommend  changing  the  flow 
of  the  process  to  have  these  two  activities  run  in  parallel. 

While  KOPeR,  in  its  diagnosis,  states  the  process  has  fiiction  in  the  forms  of 
handoffs,  inspection  of  the  process  shows  the  boarding  officer  does  the  majority  of  the 
work.  In  essence,  the  boarding  officer  is  acting  as  a  case  manager.  The  boarding  officer 
performs  the  majority  of  the  process  and  only  hands  off  the  final  documentation  to  the 
supervisor  for  review.  The  review  is  an  important  item  in  the  process  as  it  provides  a 
final  check  on  the  completeness  of  the  work  done.  Keeping  the  official  record  of  the 
boarding  electronically  could  easily  eliminate  the  hand  off  between  the  supervisor  and  a 
filing  clerk.  This  would  require  a  technology  solution  to  implement  and  may  require 
portions  of  the  process  to  be  automated;  further  discussion  of  automation  will  follow. 
The  final  hand  off  seen  between  the  filing  activity  (node  15)  and  the  log  vessel  no  boards 
(node  16),  should  not  be  counted  in  the  analysis  of  this  process.  As  discussed  above,  the 
log  vessel  no  boards  activity  is  a  separate  process;  therefore,  the  friction  from  this  hand 
off  should  not  coimt  in  the  analysis  of  the  vessel  boarding  process. 

Again,  the  remaining  recommendations  involve  information  technology.  IT 
support  for  the  vessel  boarding  process  is,  again,  supplied  by  MSIS.  This  support  is  only 
supplied  while  the  boarding  team  is  in  the  office;  there  is  no  IT  support  while  the 
boarding  team  is  on  the  vessel.  MSN  could  provide  the  same  type  of  support  that  MSIS 
provides  currently;  however,  IT  support  should  be  provided  for  the  entire  process.  IT 
support  for  the  remote  portions  of  the  vessel  boarding  process  could  be  provided  in  a 
couple  different  ways.  Providing  the  IT  support  would  require  either  a  connection  to  the 
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Interaet/CGWEB  via  a  portable  computer  or  some  sort  of  portable  database  that  could  be 
synchronized  when  the  boarding  team  returns  to  the  office. 

IT  communication  could  be  added  to  the  process  by  leveraging  MSN  as  was 
proposed  in  Section  B,  especially  for  those  parts  of  the  process  that  take  place  in  the 
office.  Linking  the  boarding  team  on  a  vessel  and  the  main  office  would  also  provide  IT 
communication  as  the  linking  would  help  to  eliminate  paper  passing  in  the  process. 
Providing  a  link  between  the  boarding  officer  on  a  vessel  and  the  main  office  is  an  area 
where  the  current  IT  infrastructure  of  the  Coast  Guard  is  lacking.  This  is  due  to  the 
complete  absence  of  any  technology  to  provide  a  link  other  than  the  cellular  telephone  or 
radio.  There  are  two  ways,  wireless  and  a  portable  application,  to  provide  the  IT 
commimication  connection  between  the  office  and  boarding  team. 

First,  wireless  connections  to  the  Internet  are  currently  the  “rage”  in  technology 
publications.  These  wireless  connections  can  take  two  different  routes  to  the  connection. 
The  first  route  is  via  a  cellular  telephone.  There  are  limitations  to  this  avenue,  the  first 
being  the  data  rate  achievable  over  such  a  connection,  and  the  other  being  dead  spots  in 
the  coverage  areas.  As  anyone  who  has  used  a  cellular  telephone  can  attest,  “dead  spots” 
are  quite  common  the  farther  away  one  moves  fi'om  xurban  environments.  The  dead  spots 
are  the  downside  for  the  cellular  telephone.  Although  the  coverage  for  cellular 
telephones  is  usually  very  good  in  metropolitan  areas,  there  are  numerous  areas  (Alaska, 
the  southern  coast  of  Oregon  and  distant  offshore  anchorages)  where  the  Coast  Guard 
performs  boardings  that  are  far  from  these  metropolitan  areas. 

The  second  route  would  be  a  wireless  option  using  a  technology  compliant  with 
the  IEEE  802.11  standard  or  some  other  proprietary  wireless  solution.  The  advertised 
range  of  these  solutions  is  fi'om  600  to  1200  feet  in  open  areas.  (Orinoco  FAQ  web  page) 
Most  of  the  proven  implementations  of  these  technologies  have  focused  on  limited 
geographic  areas  such  as  a  college  campus,  warehouse  or  hospital  complex.  (BreezeCom 
Solutions  web  page)  As  stated  for  the  cellular  telephone,  the  locations  of  vessel 
boardings  are  very  diverse.  While  the  vendors  of  these  products  are  constantly 
researching  ways  to  enhance  the  range  of  the  technology,  using  “bleeding  edge” 
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technology  for  a  production  system  is  not  cost  effective  due  to  the  lack  of  maturity  of  the 
product,  as  well  as  the  costs  involved  with  using  very  advanced  technology  (look  at  the 
cost  of  computer  systems  with  the  latest  processor  compared  to  those  with  processors  one 
or  two  generations  older).  Additionally,  due  to  the  cost  (hardware,  maintenance  and 
spares),  setting  up  a  wireless  solution  in  multiple  port  areas  would  be  expensive  and 
would  not  cover  all  areas  where  vessel  boardings  are  conducted.  While  promising,  it 
would  be  wise  to  let  the  technology  mature  in  this  area. 

The  second  approach  would  be  a  portable  computer  with  a  custom  software 
application  that  would  emulate  the  MSN  database  and  would  be  able  to  synchronize  the 
data  upon  return  to  the  office.  This  would  provide  IT  communication,  as  well  as  IT 
support,  while  on  board  the  vessel.  The  documentation  could  be  kept  online,  and 
boarding  officers  could  have  palm  size  devices  to  use  as  electronic  note  pads.  They  could 
write  comments  and  then  via  infrared  connections  add  the  comments  to  the  main 
documentation.  Making  all  documentation  electronic  would  allow  the  reduction  of  some 
hand  off  friction  in  the  process.  While  still  not  a  low  cost  option,  the  costs  involved  in 
developing  and  fielding  a  system  described  above  would  still  be  less  than  those  required 
to  establish  true  wireless  connection  in  all  of  the  areas  the  Coast  Guard  performs 
boardings.  Based  on  the  lower  costs  of  this  type  of  implementation,  I  recommend  this 
option. 

IT  automation  could  be  provided  to  the  process  by  electronic  filing  of  boarding 
records  and  by  providing  a  portable  printer  and  additional  functionality  to  the  portable 
application.  Required  paperwork,  such  as  the  boarding  letter,  could  be  printed  out  instead 
of  hand  written.  Providing  automation  to  this  process  does  not  have  as  big  a  pay  off  as 
with  the  targeting  process,  but  still  provides  some  benefits  of  reducing  cycle  time. 

As  in  Section  B,  a  view  of  the  redesigned  process  in  diagnosis  form  is  provided  to 
gain  insight  on  how  a  possible  redesign  addresses  the  diagnosis.  This  begins  with 
parallelism.  The  process  remains  sequential;  this  is  a  requirement,  as  the  extra 
information  gained  by  the  boarding  officer  is  not  offset  by  the  time  saved  by  running  the 
activities  on  the  vessel  in  parallel. 
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Next  in  the  diagnosis  is  process  friction.  The  boarding  officer  acts  as  a  case 
manager  already;  he  handles  all  of  the  activities  in  the  process  up  to  the  review  of  his 
work.  Removal  of  one  handoff  is  accomplished  by  automating  the  filing  activity  at  node 
15  in  Figure  3-2. 

IT  support,  the  next  item  in  the  diagnosis,  is  provided  by  MSN  at  the  office  and 
by  a  portable  computer  while  on  board  a  vessel.  IT  support  consists  of  keeping  track  of 
vessel  information  and  automated  note  keeping  while  on  board  the  vessel. 

Following  IT  support  is  IT  communication  which  is  provided  by  MSN  and  the 
portable  computer.  Vessel  boarding  cases  are  created  online  and  passed  to  the  supervisor 
via  the  MSN. 

The  final  diagnosis  is  IT  automation.  This  is  provided  by  the  portable  computer 
generating  the  boarding  letters  and  by  completing  the  boarding  documentation  by  passing 
it  to  the  supervisor. 

3.  Beneflts  from  Improving  the  Process 

There  are  several  benefits  to  be  gained  by  improving  the  process.  Only  those 
benefits  that  are  readily  apparent  and  tangible  will  be  addressed  in  the  section.  Other 
benefits  that  are  less  tangible  may  be  discovered  after  the  implementation  of  the  redesign, 
as  addressed  previously  in  Section  B.3.  Most  of  the  benefits  in  this  process  derive  from 
the  use  of  IT  support  and  IT  communication.  In  this  case  there  are  fewer  benefits  to  be 
gained  from  IT  automation.  Since  the  process  is  not  delinearized  there  are  no  benefits  to 
be  gained.  Regarding  the  case  manager,  the  process  already  incorporates  one  as 
discussed  above  in  Section  C.2.  The  discussion  begins  with  benefits  of  IT  support 
followed  by  IT  communication  and  IT  automation. 

Regarding  the  benefits  of  IT  support,  the  first  deals  with  consistency.  Having 
boarding  officers  use  the  same  method  of  documenting  a  boarding  will  allow  the  Coast 
Guard  to  improve  the  consistency  of  application  of  the  entire  boarding  process.  This  is 
due  to  the  fact  that  every  boarding  team  would  be  using  the  same  software  and  hardware 
packages  to  perform  the  process.  Another  benefit  is  the  increased  availability  of 
information.  Near  instantaneous  data  input  to  the  database  system  will  allow  other  MSOs 
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to  target  the  vessels  on  the  most  up  to  date  data,  reducing  the  number  of  unneeded  visits 
to  vessels. 

Regarding  the  benefits  of  IT  communication,  the  first  deals  with  data  integrity. 
Reducing  the  number  of  times  a  boarding  officer  writes  the  same  information  will 
increase  the  accuracy  of  the  data  gathered,  as  well  as  save  time  during  the  boarding  of  the 
vessel.  As  seen  with  the  copying  of  manuscripts  before  the  advent  of  the  printing  press, 
several  different  types  of  errors  could  be  made.  From  outright  errors  in  copying  the 
information,  to  less  visible  errors  such  as  changing  the  meaning  of  what  is  being  copied 
by  slightly  changing  the  wording;  these  errors  are  usually  present  in  any  manual  form  of 
copying  information.  For  example  the  translation  of  the  Bible  from  the  original  Hebrew 
to  the  King  James  Version.  Capturing  the  data  once  will  help  to  eliminate  these  errors, 
thus  reducing  the  total  number  of  errors  in  the  process.  Additionally,  the  time  saved  by 
entering  the  data  once  will  cut  down  on  the  time  spent  on  the  vessel  performing 
administrative  tasks,  such  as  copying  notes  to  the  boarding  book,  and  preparing  the  vessel 
boarding  letter. 

Another  benefit  of  IT  communication  is  reduction  in  cycle  time.  Documenting 
the  boarding  online  on  a  portable  computer  while  still  on  board  the  vessel  will  speed  the 
review  of  the  boarding  documentation.  This  will  eliminate  the  lag  between  the  boarding 
officer  returning  to  the  office,  and  the  boarding  paperwork  being  put  together  and  passed 
on  to  the  supervisor.  In  the  current  process,  this  lag  time  can  be  as  long  as  three  days. 
Having  the  boarding  documentation  complete  upon  return  will  allow  the  entry  of  the 
information  to  proceed  immediately  without  having  to  wait  for  the  boarding  officer  to 
compile  and  turn  in  the  case  work. 

Finally,  the  benefits  of  IT  automation  are  reduction  in  cycle  time  and  reduction  of 
handoff  friction.  The  reduction  in  cycle  time  stems  from  the  use  of  a  portable  computer 
and  printer  to  create  the  boarding  letter  left  on  the  vessel.  The  electronic  filing  of  the 
boarding  documentation  in  the  central  database  provides  the  reduction  of  handoff  friction. 
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D.  SUMMARY 


This  chapter  has  covered  the  current  PSC  process  in  two  parts,  the  targeting 
process  and  the  vessel  boarding  process.  Each  of  the  processes  was  described  and  then 
analyzed  using  measurement  based  inference  to  diagnose  the  BPR  pathologies.  From 
those  pathologies,  generic  recommendations  were  provided  which  were  then  made  more 
specific  through  the  use  of  manual  analysis  from  my  first  hand  knowledge  of  the  process. 
Finally,  benefits  of  improving  the  processes  were  identified. 

The  most  important  part  of  this  chapter,  to  carry  on  to  the  next  chapter,  is  the 
recommendations  on  how  to  improve  the  processes.  The  recommendations  are:  use  of 
client/server  architecture,  automation  of  the  process,  leveraging  off  current  IT 
infrastructure,  and  a  web  enabled  database.  These  are  foundational  for  the  redesign 
efforts  of  the  processes.  The  next  chapter  presents  the  redesigned  processes,  and  using 
simulation,  provide  some  tangible  evidence  that  the  redesign  will  significantly  improve 
the  process. 
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IV.  PROCESS  REDESIGN 


The  two  major  PSC  subprocesses  have  been  redesigned  based  upon  the  diagnosis 
of  the  pathologies  of  the  overall  process  presented  in  Chapter  III.  The  redesign  takes  into 
account  the  fiscal  constraints  of  the  Coast  Guard  and  the  recommendations  found  in 
Chapter  III.  An  explanation  of  the  redesigned  processes  and  presentation  of  simulation 
models  for  the  current  and  redesigned  processes  are  presented  below. 

A.  REDESIGN  OF  THE  TARGETING  PROCESS 

1.  Model  and  Description  of  the  Proposed  Process 

As  in  Chapter  III  for  the  current  processes,  I  use  the  model  of  the  proposed 
process  to  guide  the  discussion  of  the  process  activities.  The  proposed  process  model  is 
presented  as  Figure  4-1. 

Activity  node  1:  Enter  vessel  arrival  information.  The  redesigned  targeting 
process  begins  with  the  vessel  agent  entering  the  arrival  of  a  vessel  on  a  web  page  linked 
to  the  MSN  database  system.  The  information  on  the  agent,  the  vessel,  and  the  arrival 
date  are  captured  and  entered  into  the  database. 

Activity  node  2:  Vessel  grading.  At  the  server,  the  database  is  queried  for 
additional  vessel  information,  and  the  results  of  the  query  are  submitted  to  a  grading 
algorithm,  which  generates  a  grading  profile  to  the  agent  via  a  dynamic  web  page.  Based 
on  the  profile,  the  agent  gains  insight  about  whether  the  vessel  is  a  likely  candidate  for 
boarding  during  the  port  call. 

Activity  node  3:  Log  grading  results.  The  grading  profile  data  are  stored  with  the 
arrival  information  for  later  retrieval. 

Activity  node  4:  Boarding  decisions  made.  The  supervisor  of  the  PSC  branch  at 
the  MSO  accesses  a  web  page  that  shows  the  vessels  due  to  arrive  and  vessels  already  in 
port  for  their  area  of  responsibility.  The  vessel  information  is  listed  by  priority  with  the 
highest  priority  vessels  listed  first.  Vessels  with  the  same  priorities  are  ranked  by  a 
decision  support/expert  system  that  uses  data  mining  and/or  a  multi-criteria  decision 
model  to  rank  relevant  risk  items  on  the  vessel  and  provide  a  recommendation  on  which 
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vessels  pose  the  most  risk.  The  vessels  selected  for  boardings  that  day  are  checked  off, 
and  the  information  is  submitted  to  the  server.  The  server  returns  a  confirmation  of  the 
vessels  selected  and  stores  the  information  for  further  retrieval  as  well  as  for  subsequent 
use  in  the  boarding  process. 

Activity  node  5:  Boarding  teams  dispatched.  Boarding  teams  are  assigned  to  the 
vessels  selected  for  boardings. 


Activity  name 


Agent 


IT  Support 


To  vessel  boarding  process. 


Figure  4-1 .  Redesigned  Targeting  Process 
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This  redesign  relies  heavily  upon  information  technology  for  successful 
implementation.  The  client/server  architecture  allows  for  inexpensive  implementation, 
centralized  maintenance,  and  facilitation  of  the  familiar  web  browser  interface  to 
complete  the  process.  Additionally,  the  use  of  the  client/server  architecture  leverages  the 
investment  the  Coast  Guard  has  made  in  the  Standard  Workstation  III  contract. 

The  redesign  described  above  is,  in  my  opinion,  an  optimal  redesign  for  the 
process,  and  is  the  one  modeled  in  this  Chapter.  However,  I  have  provided  two  variations 
of  the  process,  which  incorporate  the  core  elements  of  the  redesign  because  I  see  two 
areas  of  resistance  by  the  Coast  Guard  and  industry  regarding  the  full  implementation  of 
the  redesigned  process. 

The  first  area  of  resistance  stems  from  the  vessel  agents  entering  the  vessel 
arrivals  on  a  web  page  as  opposed  to  using  a  telephone  to  call  in  the  arrival.  To 
overcome  this  resistance,  a  possible  variation  on  the  redesigned  process  is  to  eliminate 
the  requirement  of  entering  the  vessel  arrival  information  on  a  web  page.  This  variation 
would  have  the  agent  call  in  the  arrival  information  to  a  watchstander,  as  in  the  current 
process,  who  then  uses  a  web  page  to  enter  the  data  in  the  database  for  grading.  In  this 
case,  the  beginning  of  the  process  would  be  the  same  as  the  current  process  so  the  vessel 
agent  sees  no  change. 

The  second  area  of  resistance  may  be  from  those  ports  that  have  a  centralized 
broker.  These  brokers  take  the  arrival  information  from  the  vessel  agents  and  then 
provide  the  information  to  the  Coast  Guard  under  a  special  agreement.  In  most  cases,  the 
centralized  brokers  have  a  more  involved  relationship  with  the  Coast  Guard  than  just 
providing  vessel  information  such  as  providing  vessel  traffic  control.  Removing  this  one 
service  may  damage  the  relationship  between  the  Coast  Guard  and  the  broker.  In  this 
case,  the  variation  would  be  that  vessel  arrivals  would  still  be  provided  by  the  broker, 
thus  reinforcing  the  relationship.  The  vessel  arrivals  would  be  entered  into  the  database 
via  the  web  page  by  a  petty  officer  in  the  PSC  branch. 

To  help  quantify  the  advantages  of  the  redesign,  simulation  models  of  the  current 
and  proposed  processes  have  been  created  in  EXTEND+BPR®.  These  models  are 
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designed  to  capture  the  critical  performance  measures  of  the  process  in  a  consistent 
manner  to  allow  meaningful  comparisons  of  the  two  processes.  Unless  noted  otherwise, 
the  parameters  used  in  the  models  are  estimated  from  three  years  (1996-1998)  of  my 
personal  experience  (i.e.,  as  a  subject  matter  expert)  in  directly  performing  and 
supervising  the  PSC  process.  This  is  a  limitation  that  is  discussed  later  in  this  Chapter. 

Figures  4-2  and  4-3  present  portions  of  an  EXTEND+BPR@  simulation  model 
covering  the  targeting  process.  Several  major  assumptions  have  been  made  in  the  design 
of  the  model,  which  will  be  identified  during  the  course  of  the  step-by-step  model 
discussion. 


Figure  4-2.  Current  PSC  Targeting  Simulation  Model,  Part  1 


Vfels  to  be  boarded 


Figure  4-3.  Current  PSC  Targeting  Simulation  Model,  Part  2 
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The  model  starts  in  step  one  with  a  repository  of  vessels  randomly  selected  from  a 
uniform  distribution  with  a  minimum  and  maximum  of  two  and  15,  respectively.  This 
simulates  an  average  daily  number  of  arrivals  for  a  medium  to  large  sized  port  such  as 
Los  Angeles  or  New  Orleans.  Ports  of  this  size  will  likely  benefit  the  most  from  the 
redesign  due  to  the  larger  number  of  vessel  arrivals,  and  subsequently  the  greater  amount 
of  time  spent  performing  the  PSC  process. 

Step  two  consists  of  a  timer,  which  allows  for  the  computation  of  cycle  time  for 
each  vessel  moving  through  the  system. 

Step  three  is  a  transaction  block,  which  represents  the  agent  calling  in  the  vessel 
arrival  to  a  watchstander.  The  time  for  this  transaction  is  assumed  to  be  fixed  at  three 
minutes  per  vessel,  due  to  the  routine  nature  of  the  information  passed  and  the  familiarity 
of  the  vessel  agents  with  the  information  requirements. 

In  step  four  the  information  flows  to  a  holding  or  repository  block,  which 
represents  the  log  sheet  the  watchstander  has  filled  out  containing  the  arrival  information. 

Step  five  is  a  transaction  block  that  simulates  the  time  it  takes  for  the  entry  of 
information  into  the  MSIS  system.  The  time  for  this  transaction  is  assumed  to  be  fixed  at 
three  minutes  per  vessel,  again  because  this  is  a  routine  activity  with  very  structured 
information  requirements. 

Step  six  is  the  First  In,  First  Out  (FIFO)  queue,  which  simulates  the  stack  of 
vessel  histories  waiting  to  be  graded,  on  a  first  item  in  first  item  out  basis. 

Step  seven  is  a  transaction  block  that  simulates  the  grading  of  the  vessels.  The 
time  for  the  grading  of  the  vessel  is  randomly  assigned  from  a  real,  uniform  distribution 
with  min  and  max  values  of  two  and  five  minutes  per  vessel,  respectively.  This 
assumption  captures  the  varying  nature  of  vessel  histories,  and  the  human  factor  involved 
in  the  grading  of  the  vessels. 

Step  eight  is  the  transaction  block  that  simulates  the  supervisor’s  review  of  the 
vessel  grading  sheets.  Again,  the  time  for  this  block  is  assigned  from  a  real,  uniform 
distribution  with  min  and  max  values  of  two  and  eight  minutes  per  vessel,  respectively. 
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This  assumption  simulates  the  range  of  mistakes  that  may  be  made  filling  out  the  grading 
sheets,  and  the  associated  complexity  of  the  information  being  reviewed. 

Step  nine,  the  boarding  decision,  is  broken  into  two  different  blocks,  A  and  B,  one 
for  the  time  it  takes  to  make  the  boarding  decision,  and  one  for  implementing  the 
decision.  Block  A  is  the  transaction  block  that  simulates  the  time  it  takes  to  make  the 
boarding  decision  on  each  vessel.  The  time  interval  for  the  transaction  block  for  the 
decision  is  assumed  to  be  between  one  and  five  minutes  per  vessel  from  a  real,  uniform 
distribution.  This  takes  into  account  the  time  it  may  take  to  decide  between  two  or  more 
vessels.  Block  B,  the  decision  block,  does  not  have  a  time  delay.  This  block  is  set  up  to 
provide  a  boarding  ratio  of  0.25.  This  means  that  for  ten  vessel  arrivals,  one  fourth  of 
those  vessels  will  be  selected  for  a  boarding.  The  decision  block  is  set  up  to  send  a  vessel 
to  the  boarding  area  of  the  simulation,  if  the  random  number  provided  as  the  input  is  0.25 
or  less;  otherwise,  the  vessel  is  sent  to  the  not  boarded  area  of  the  simulation.  Since  the 
decision  to  board  is  based  on  a  random  number  from  a  real,  uniform  distribution,  a 
simulation  run  may  see  a  boarding  ratio  that  is  more  or  less  than  0.25.  This  simulates  the 
average  USCG  boarding  rate  of  vessels  calling  at  US  ports  for  the  year  of  1998,  the  last 
year  for  which  complete  statistics  are  available  at  this  time.  Although  the  0.25  ratio  is  the 
simulation  average  for  USCG  boardings,  this  should  not  imply  there  is  always  the 
manpower  available  to  board  all  the  vessels  needing  a  boarding  that  arrive  the  same  day. 
Not  boarding  a  vessel  the  same  day  it  arrives  is  acceptable  as  vessels  usually  stay  in  port 
for  a  period  longer  than  one  day.  In  addition,  it  should  be  noted  that  the  boarding  ratio  of 
0.25  is  not  a  mandated  target,  but  rather  a  naturally  occurring  phenomenon.  The  Coast 
Guard  has  a  requirement  to  board  vessels  at  a  six  month  interval,  and  the  0.25  boarding 
ratio  seems  to  occur  naturally  because  of  this,  as  the  ratio  consistently  appears  on  annual 
reports,  both  nationally  and  at  local  unit  levels. 

Step  ten  is  the  final  part  of  the  simulation  model.  This  decision  block  simulates 
the  assignment  of  boarding  teams.  It  is  assumed  that  there  is  no  time  delay,  as  the 
tracking  of  personnel  lies  outside  the  scope  of  this  thesis.  A  summary  of  the  parameters 
for  the  blocks  in  the  simulation  model  is  presented  in  Table  4-1. 
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Block  Name 

Fixed/Random 

Distribution 

random 

Integer,  Uniform 

3 

fixed 

N/A 

Enter  &  Print 

3 

fixed 

N/A 

(2.0,  5.0) 

random 

Real,  Uniform 

(2.0,  8.0) 

random 

Real,  Uniform 

Bdng  Decision 

(1.0,  5.0) 

random 

Real,  Uniform 

Boarding  Decision 

(0.0,  1.0) 

random 

Real,  Uniform 

Table  4-1. 

Current  Targeting  Process  Simulation  Model 

Parameters 

A  final  assumption,  not  explicit  in  the  model  itself  (due  to  the  fact  that  this 
variable(s)  is  extremely  unpredictable),  is  that  the  personnel  working  on  the  process  are 
focused  solely  on  completing  the  tasks  of  the  process  with  no  interruptions.  Modeling  of 
this  type  of  uncertainty  is  not  needed  for  the  comparison  purposes  of  cycle  time,  but  is 
necessary  to  mention,  as  it  is  a  possible  limitation  of  the  simulation  model.  Additionally, 
since  controlling  interruptions  to  the  personnel  performing  the  process  is  very  difficult  in 
the  real  world,  modeling  the  uncertainty  of  this  variable  would  serve  best  as  a  topic  of  a 
separate  thesis. 

At  this  point  the  simulation  model  is  used  to  compute  the  baseline  average  cycle 
time  of  the  current  process,  one  of  the  critical  performance  measures  identified  in  Chapter 
II.  Ten  runs  of  the  simulation  model  described  above  are  conducted.  This  means  that  a 
random  number  of  vessel  arrivals  will  run  through  the  model  for  each  of  the  ten  runs. 
This  would  simulate  ten  days  in  the  life  of  the  PSC  process.  The  full  data  for  the 
simulation  runs  as  well  as  the  statistics  (mean,  max,  min  and  standard  deviation)  for  each 
run,  and  the  overall  statistics  are  presented  in  Table  4-2.  Each  column  in  the  table 
represents  a  run  of  the  simulation  model.  Each  cell  in  each  column  represents  a  vessel 
arrival,  and  the  time  it  took  for  each  vessel  to  move  through  the  simulation  model. 
Discussion  and  interpretation  of  the  results  are  covered  later  in  this  chapter. 
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Sim# 

1 

2 

3 

4 

IHH 

8 

9 

10 

Ship  #1 

15.19 

15.81 

20,97 

19.38 

10.33 

IB 

16.72 

17.13 

14.81 

Ship  #2 

13.56 

19.78 

17.01 

16.72 

12.14 

IB 

17.27 

15.27 

15.63 

Ship  #3 

14.39 

19.12 

9.98 

15.88 

19.11 

17.79 

13.81 

Ship  #4 

20.84 

17.24 

13.39 

12.77 

17.45 

15.73 

Ship  #5 

14.86 

15.62 

15.79 

16.14 

16.15 

Ship  #6 

19.89 

16.95 

15.47 

19.58 

17.18 

Ship  #7 

14.07 

13.89 

16.22 

16.72 

Ship  #8 

14.78 

17.12 

Ship  #9 

13.22 

16.85 

15.41 

15.07 

Ship  #10 

Ship  #11 

18.68 

Ship  #12 

Ship  #13 

Ship  #14 

Ship  #15 

18.71 

Mean: 

15.32 

18.24 

18.99 

15.88 

11.23 

16.15 

1  18.38 

15.71 

17.44 

15.32 

Max: 

20,84 

19.78 

20.97 

19.11 

19.93 

17.18 

Min: 

12.39 

15.81 

17.01 

9.98 

IWcH 

12.77 

15.27 

11.65 

Std  Dev: 

2.80 

2.13 

2.24 

1.91 

1.91 

1.64 

1.63 

Totals: 

Mean: 

16.08 

Max: 

20.97 

Min: 

9.98 

SDev; 

2.46 

Table  4-2.  Simulation  Delay  Times  for  the  Current  Targeting  Process 


The  other  critical  performance  measure  identified  in  Chapter  II  is  data  accuracy. 
Data  accuracy  is  measured  by  counting  the  number  of  times  data  relating  to  a  vessel  is 
copied  to  another  place,  either  on  paper  or  as  data  input  into  a  computer  database.  As 
borne  out  in  experience  with  manuscripts  before  the  advent  of  the  printing  press,  it  is 
assumed  that  the  smaller  the  number  of  transcriptions,  the  more  accurate  the  data.  This  is 
more  of  a  qualitative  measure  as  opposed  to  a  quantitative  one.  The  value  of  the  data 
accuracy  measure  for  the  current  targeting  process  is  four. 

Figure  4-4  is  a  portion  of  the  EXTEND+BPR®  simulation  model  for  the 
redesigned  targeting  process.  As  above,  the  assumptions  of  the  model  are  explained  by 
following  the  flow  of  information  through  the  model. 
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Figure  4-4.  Simulation  Model  for  the  Redesigned  Targeting  Process 

This  model  begins  with  a  repository  of  vessels,  the  number  of  which  is  randomly 
assigned  exactly  as  done  with  the  model  of  the  current  process. 

Step  two  is  a  timer  block  which  allows  for  the  computation  of  cycle  time  for  each 
vessel  moving  through  the  system. 

Step  three  is  the  first  transaction  block.  This  simulates  the  agent  logging  the 
arrival  information  into  the  web  page.  This  activity  is  assumed  to  be  a  constant  of  three 
minutes  per  vessel  to  account  for  the  agent  logging  in  and  then  entering  the  pertinent 
information. 

Step  four  is  the  second  transaction  block.  This  simulates  the  server  running  the 
grading  and  logging  process.  This  process  is  assumed  to  require  a  time  randomly  selected 
from  a  uniform  distribution  with  a  minimum  and  maximum  of  one  and  two  minutes, 
respectively.  This  is  to  account  for  varying  traffic  loads  on  the  server,  bandwidth  and 
complexity  of  the  vessel  record. 

Step  five  is  the  third  transaction  block.  This  block  simulates  the  supervisor 
reviewing  the  vessels  for  boarding.  Since  this  is  a  computerized  list,  the  time  to  complete 
the  review  of  the  list  is  fixed  at  one  minute  per  vessel. 
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Step  six  is  the  boarding  decision.  Like  the  current  process  model,  this  step  is 
implemented  with  two  blocks,  A  and  B.  Block  A  is  the  boarding  decision  transaction 
block,  which  is  assumed  to  have  a  delay  time  of  one  to  three  minutes  per  vessel.  This 
accounts  for  the  time  taken  by  a  human  supervisor  to  decide  on  the  vessels  to  board  even 
when  given  a  list  supported  by  a  decision  support  system.  Block  B  is  the  actual  boarding 
decision  block.  It  is  configured  the  same  as  the  boarding  decision  block  for  the  current 
simulation  model. 

The  rest  of  the  simulation  model  is  identical  to  the  model  for  the  current 
simulation  model.  A  summary  of  the  parameters  for  this  simulation  model  is  presented  in 
Table  4-3. 


Block  Name 

Value/Range 

Fixed/Random 

Distribution 

#  Vessel  Arrivals 

(2.0, 15.0) 

random 

Integer,  Uniform 

Agent  Call  in 

3 

fixed 

N/A 

Grade  &  Log 

(1.0,  2.0) 

random 

Real,  Uniform 

Supervisor  Rvw 

1 

fixed 

N/A 

Bdng  Decision,  time 

(1.0,  3.0) 

random 

Real,  Uniform 

Boarding  Decision 

(0.0, 1.0) 

random 

Real,  Uniform 

Table  4-3.  Redesign  Targeting  Process  Simulation  Model  Parameters,  Most  Likely 

Scenario 


At  this  point,  the  simulation  model  is  used  to  compute  the  average  cycle  time  of 
the  redesigned  process.  To  provide  a  full  range  of  simulation  numbers,  three  different 
scenarios  were  developed,  most  likely,  optimistic  and  pessimistic.  The  parameters  for  the 
most  likely  scenario  were  determined  by  estimating  a  range  of  the  time  saved  for  each 
activity.  Based  off  the  most  likely  scenario  parameters,  high  and  low  limits  for  each 
activity  were  estimated,  thus  providing  the  set  of  parameters  for  the  optimistic  and 
pessimistic  scenarios.  Again,  these  estimates  were  based  on  my  own  personal 
experience,  stated  earlier  in  this  Chapter.  The  parameters  for  the  most  likely  scenario  are 
presented  in  Table  4-3.  The  parameters  for  the  optimistic  and  pessimistic  scenarios  are 
provided  as  Tables  4-4  and  4-5  respectively.  For  each  scenario,  ten  runs  of  the 
simulation  were  conducted.  This  was  done  to  get  the  process  cycle  times  for  comparison 
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with  the  baseline  number.  The  full  data  for  the  most  likely,  optimistic  and  pessimistic 
scenario  runs  are  presented  in  Tables  4-6, 4-7  and  4-8  respectively. 


Block  Name 

Value/Range 

Fixed/Random 

Distribution 

#  Vessel  Arrivals 

(2.0,  15.0) 

Random 

Integer,  Uniform 

Agent  Call  in 

2 

Fixed 

N/A 

Grade  &  Log 

(0.5,  1.5) 

Random 

Real,  Uniform 

Supervisor  Rvw 

0.5 

Fixed 

N/A 

Bdng  Decision,  time 

(0.5,  1.5) 

Random 

Real,  Uniform 

(0.0,  1.0) 

Random 

Real,  Uniform 

Table  4-4.  Redesign  Targeting  Process  Simulation  Model  Parameters,  Optimistic 


Scenario 


Block  Name 

Value/Range 

Fixed/Random 

Distribution 

#  Vessel  Arrivals 

(2.0,  15.0) 

Random 

Integer,  Uniform 

Agent  Call  in 

4 

Fixed 

N/A 

Grade  &  Log 

(2.0,  3.0) 

Random 

Real,  Uniform 

2 

Fixed 

N/A 

Bdng  Decision,  time 

(2.0,  4.0) 

Random 

Real,  Uniform 

Boarding  Decision 

(0.0,  1.0) 

Random 

Real,  Uniform 

Table  4-5.  Redesign  Targeting  Process  Simulation  Model  Parameters,  Pessimistic 


Scenario 
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Sim# 

1 

2 

3 

4 

5 

6 

7 

10 

Ship  #1 

7.10 

7.08 

7.25 

7.75 

8.35 

7.80 

6.78 

8.26 

Ship  #2 

6,50 

8.34 

7.06 

8.10 

10^ 

BK! 

7.04 

7.43 

Ship  #3 

8.28 

7.41 

7.17 

6.34 

8.25 

W:ftH 

7.71 

7.44 

Ship  #4 

8.05 

8.46 

8.39 

Ship  #5 

8.13 

igng 

7.00 

Ship  #6 

7.52 

8.04 

7.49 

6.67 

7.69 

7.76 

Ship  #7 

6.70 

7.74 

8.05 

8.46 

7.02 

Ship  #8 

7.89 

8.08 

6.53 

7.72 

■ISl 

Ship  #9 

8.78 

7.42 

7.61 

7.36 

6.65 

Ship  #10 

7.59 

8.22 

7.82 

8.47 

7.15 

Ship  #11 

9.81 

9.52 

Ship  #12 

9.34 

Ship  #13 

8.90 

Ship  #14 

Ship  #15 

Mean: 

7.58 

7.21 

8.02 

7.64 

7.66 

Max: 

8.34 

8.34 

8.35 

8.25 

8.46 

8.47 

8.01 

8.69 

Min: 

6.50 

6.53 

6.13 

7.80 

6.78 

7.43 

Std  Dev: 

0.63 

0,54 

0.74 

B 

Totals: 

Mean: 

7.58 

Max: 

8.78 

Min: 

6.13 

Sdev: 

0.64 

Table  4-6.  Simulation  Delay  Times  for  the  Redesigned  Targeting  Process,  Most  Likely 

Scenario 
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Sim# 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Ship  #1 

4.06 

IKE! 

4.00 

4.07 

3.75 

4.61 

4.49 

Ship  #2 

4.85 

4.85 

4.47 

4.70 

lOES 

IKKE 

5.32 

4.50 

Ship  #3 

4.07 

4.72 

4.79 

4.33 

OHSI 

5.31 

4.83 

4.31 

4.20 

4.35 

Ship  #4 

5.21 

4.26 

4.19 

4.68 

4.46 

4.85 

Ship  #5 

4.54 

4.52 

4.33 

I3IQ33 

4.97 

5.02 

4.14 

Ship  #6 

4.55 

4.43 

5.00 

4.57 

3.94 

4.72 

Ship  #7 

3.84 

4.34 

4.77 

4.58 

4.39 

Ship  #8 

4.26 

4.32 

3.92 

3.69 

3.98 

Ship  #9 

4.70 

1031 

4.98 

4.24 

Ship  #10 

3.92 

4.18 

KOI 

Ship  #11 

5.27 

5.50 

Ship  #12 

5.51 

Ship  #13 

5.51 

Ship  #14 

Ship  #15 

Mean: 

4.40 

'  4.47 

4.63 

4.60 

4.46 

4.49 

Max; 

5.21 

5.19 

5.31 

5.05 

5.13 

5.32 

4.85 

3.98 

4.24 

3.97 

3.92 

3.75 

3.69 

4.05 

3.94 

4.14 

Std  Dev: 

0.44 

0.37 

0.41 

0.61 

0.43 

0.24 

Totals: 

Mean: 

4.50 

Max: 

5.32 

Min: 

3.69 

Sdev: 

0.42 

Table  4-7.  Simulation  Delay  Times  for  the  Redesigned  Targeting  Process,  Optimistic 

Scenario 
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Sim# 

1 

2 

in 

7 

8 

9 

10 

Ship  #1 

12.12 

11.12 

12.50 

10.90 

12.14 

Ship  #2 

12.15 

12.67 

11.37 

Ship  #3 

i■ul;w 

11.53 

10.32 

Ship  #4 

Kliisn 

10.89 

12.91 

11.50 

11.52 

Ship  #5 

10.72 

10.66 

10.28 

10.65 

11.11 

Ship  #6 

11.57 

12.09 

11.51 

12.47 

12.09 

Ship  #7 

11.47 

10.41 

11,69 

10.45 

11.55 

11.10 

11.18 

Ship  #8 

11.10 

11.50 

11.31 

11.94 

11.11 

Ship  #9 

11.99 

10.85 

10.07 

11.76 

12.59 

11.90 

Ship  #10 

11.95 

10.57 

11.21 

10.66 

11.30 

Ship  #11 

13.65 

13.81 

14.52 

14.85 

Ship  #12 

14.05 

13.75 

14.28 

15.04 

13.77 

14.48 

14.54 

Ship  #14 

12.93 

13.23 

Ship  #15 

14.15 

11.30 

11.50 

11.67 

11.38 

Max: 

12.15 

12.09 

11.94 

12.08 

12.62 

12,59 

12.10 

12.14 

Min: 

10.72 

10.07 

10.86 

10.32 

Std  Dev: 

0.53 

0.44 

0.98 

0.70 

0.65 

0.55 

0.51 

0.52 

Totals: 

Mean: 

11.47 

Max: 

12.91 

Min: 

o 

b 

SDev: 

0.63 

■■1 

Table  4-8.  Simulation  Delay  Times  for  the  Redesigned  Targeting  Process,  Pessimistic 

Scenario 

2.  Comparison  Against  the  Current  Process 

Comparing  the  current  process  against  the  redesign  immediately  shows  the 
improvements  achieved  using  information  technology.  Not  only  has  the  length  of  the 
process  decreased,  but  the  handoffs  and  number  of  transcriptions  have  also  been  reduced. 

Table  4-9  presents  a  comparison  of  the  current  and  redesigned  process 
configuration  measurements.  The  configuration  measurements  were  discussed  and 
defined  in  Chapter  III. 


Configuration  Measure 

Current  Process  Value 

Redesigned  Process  Value 

Process  Size 

8 

5 

Process  Length 

8 

3 

Handoffs 

3 

2 

Feedback  loops 

1 

1 

IT- Support 

1 

4 

IT-Communication 

0 

4 

IT- Automation 

0 

3 

Table  4-9.  Comparison  of  Configuration  Measures 


There  are  two  items  to  note  concerning  the  redesigned  process  values  in  Table  4- 
9.  First,  the  process  length  is  three;  this  number  is  arrived  at  by  considering  activities  one 
through  three  (see  Figure  4-1)  as  running  in  parallel  with  the  two  other  activities  in  the 
process.  The  second  item  to  note  is  the  dramatic  increase  in  IT  support,  IT 
communication  and  IT  automation.  These  items  are  the  result  of  the  application  of 
technology  to  the  process. 

To  further  compare  the  two  processes  the  configuration  measures  in  Table  4-9  are 
given  to  KOPeR  for  redesign  diagnosis.  The  resulting  diagnosis  is  shown  in  Table  4-10 
along  with  the  diagnosis  for  the  current  targeting  process. 


Measure  Name 

(Numeric)  -  Diagnosis 

Current  Process 

Redesigned  Process 

Parallelism 

(1.0)  -  sequential  process 

(1.667)  -  sequential  process 

Handoffs  fraction 

(0.375)  -  process  friction 

(0.4)  -  process  friction 

Feedback  fraction 

(0.125)  -  feedback  looks  OK 

(0.2)  -  feedback  looks  OK 

IT  support  fraction 

(0.125)  -  inadequate  IT 
support 

(0.8)  -  IT  support  looks  OK 

IT  communication 
fraction 

(0.0)  -  inadequate  IT 
communications 

(0.8)  -  IT  communication 
looks  OK 

IT  automation 
fi'action 

(0.0)  -  IT  automation  first 
requires  substantial 
infi'astructure  in  terms  of 
support  and  communication. 

(0.6)  -  IT  automation  looks 

OK 

Table  4- 1 0.  Comparison  of  Diagnoses 


In  the  areas  of  parallelism,  handoffs,  and  feedback  the  diagnosis  does  not  show 
any  difference  between  the  current  and  redesigned  processes.  The  numbers  for  these 
three  measures  have  improved,  but  not  to  the  point  where  KOPeR  would  change  the 
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diagnosis.  The  diagnosis  for  IT  support,  IT  communication  and  IT  automation  have  gone 
from  inadequate  to  OK;  therefore,  the  redesign  has  succeeded  in  eliminating  three 
negative  diagnoses. 

Another  area  for  comparison  between  the  current  and  redesigned  processes  is  with 
the  results  of  the  simulation  runs.  Comparing  the  numbers  from  the  runs  of  the  three 
different  scenarios,  the  simulation  model  shows  cycle  time  reductions.  The  cxirrent 
process  cycle  time  average  is  16.1  minutes  per  vessel.  Regarding  the  most  likely 
scenario,  the  cycle  time  is  7.6  minutes  per  vessel,  a  reduction  in  cycle  time  of  8.5 
minutes,  or  52.6%,  per  vessel.  For  the  optimistic  scenario,  the  cycle  time  is  4.5  minutes 
per  vessel,  a  reduction  in  cycle  time  of  11.6  minutes,  or  72%,  per  vessel.  For  the 
pessimistic  scenario,  the  cycle  time  is  1 1.5  minutes  per  vessel,  a  reduction  in  cycle  time 
of  4.6  minutes,  or  28.6%,  per  vessel.  A  summary  of  the  cycle  times,  savings  and  percent 
reductions  is  provided  as  Table  4-11. 


Scenario 

Cycle  Time 

Reduction 

%  Reduction 

Man  Years  Saved 

Current 

16.1  min 

N/A 

N/A 

N/A 

Optimistic 

4.5  min 

11.6  min 

72.0% 

2.8 

Most  Likely 

7.6  min 

8.5  min 

52.6% 

2.1 

Pessimistic 

1 1 .5  min 

4.6  min 

28.6% 

1.1 

Table  4-11.  Summary  of  Cycle  Time  Savings  by  Scenario 


To  provide  a  measure  of  the  amount  of  time  saved  annually  by  the  redesigned 
process,  I  separately  aggregate  the  simulation  numbers  from  each  of  the  three  scenarios. 
These  numbers  are  aggregated  with  the  1 1  ports  that  have  large  PSC  programs  (defined 
as  having  more  than  400  examinations  in  a  year  based  on  the  1998  Annual  PSC  report). 
Based  on  simulated  vessel  arrivals  of  two  to  15  vessels  a  day,  an  average  number  of 
vessel  arrivals  is  7.5.  Assuming  7.5  vessel  arrivals  a  day  per  port  and  a  boarding  ratio  of 
0.25,  the  time  saved  would  be:  4265.9  hours  per  year  for  the  most  likely  scenario; 
5821.75  hours  per  year  for  the  optimistic  scenario;  and  2308.6  hours  per  year  for  the 
pessimistic  scenario.  (The  hours  per  year  were  calculated  with  the  following  formula: 
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total  number  hours  saved  yearly  ==  minutes  saved  X  number  of  vessels  X  (365  days  in  a 
year  -r  60  minutes)  X  11  ports)  This  equates  to  approximately  2.1  man-years  saved  for 
the  most  likely  scenario,  2.8  man-years  for  the  optimistic  scenario,  and  1.1  man-years  for 
the  pessimistic  scenario,  and  only  for  the  1 1  ports  with  large  PSC  programs. 

Comparing  the  critical  performance  measure  of  data  accuracy  of  the  current 
process  to  the  redesigned  process,  the  number  of  transcriptions  has  been  reduced  from 
four  to  one.  This  points  to  a  much  more  accurate  process  which  reduces,  if  not 
eliminates,  the  amount  of  rework  that  is  required  by  the  current  process.  Further,  having  a 
single  point  of  entry  for  all  data  will  strengthen  data  integrity  of  the  overall  system. 

The  number  of  people  required  to  perform  the  redesigned  process  has  also  been 
reduced.  Removing  the  watchstander,  and  the  person  performing  the  data  entry  and 
grading  removes  two  people  from  the  process.  In  addition  to  the  manpower  savings  from 
cycle  time  reduction  mentioned  above,  removing  two  personnel  from  the  process  saves 
approximately  1.4  man  years  annually.  (This  is  calculated  by  taking  the  six  minutes  per 
vessel  the  two  personnel  would  be  spending  in  the  current  process  and  performing  a 
calculation  as  shown  above.)  Additionally,  removing  the  personnel  frees  them  to  perform 
other  duties.  Making  the  grading  computerized  and  less  prone  to  errors  also  decreases 
the  amount  of  time  the  supervisor  requires  for  review  of  work,  thus  freeing  him  to 
concentrate  on  other  important  issues. 

If  the  process  variation  described  in  Section  1  above  is  adopted  (i.e.,  the  vessel 
agent  calling  in  to  a  watchstander  or  a  centralized  information  broker  is  used),  there  is 
still  an  improvement  in  cycle  time  and  a  reduction  in  errors,  although  not  as  dramatic  as 
above.  This  improvement  in  cycle  time  is  due  to  the  removal  of  the  data  entry  and  vessel 
grading  person  from  the  process,  but  this  is  in  no  way  a  removal  of  the  watchstander  who 
is  required  to  take  vessel  arrival  information.  Regarding  data  errors,  the  computerized 
grading  would  reduce  them.  However,  the  improvements  in  data  errors  would  not  be  as 
great  as  the  results  seen  for  the  full  redesign,  because  the  watchstander  is  still  involved  in 
the  process. 
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The  redesigned  process  also  leverages  technology  better  than  the  current  process. 
The  entire  redesigned  process  is  supported  by  a  web-enabled  database,  whereas  the 
current  process  relies  upon  multiple  handwritten  lists  and  manual  evaluation.  Although 
there  are  costs  involved  in  developing,  implementing  and  maintaining  such  a  system,  the 
costs  associated  with  building  from  an  already  existing  and  evolving  MSN  would  be 
significantly  less  than  if  the  system  were  implemented  from  scratch.  This  is  compatible 
with  the  Coast  Guard  development  strategy  of  continuously  evolving  software  as  opposed 
to  developing  a  static,  finished  product. 

3.  Advantages  of  the  Proposed  Process 

There  are  niunerous  advantages  to  the  proposed  process  over  the  current  process. 
The  advantages  in  reducing  cycle  time  and  the  number  of  data  transcriptions  are  the  most 
telling,  as  those  are  the  critical  performance  measures  for  the  redesign  to  be  successful. 
There  are  other  advantages  that  can  also  benefit  the  overall  organization  significantly: 

1.  Removing  additional  personnel  from  the  process  by  using  technology  frees 
those  personnel  to  perform  other  duties  at  the  unit. 

2.  Reducing  the  amount  of  time  spent  on  rework  and  review  allows  those 
involved  in  the  process  more  time  to  perform  other  work  or  hone  their  skills  to 
perform  the  physical  inspection  better. 

'  3.  Having  the  vessel  agent  input  the  data  and  then  receive  feedback  on  the 
priority  of  the  vessel  gives  the  agent  a  better  feel  of  what  to  expect  for  the  port 
call.  This  can  lead  to  the  vessel  personnel  being  ready  for  the  exam  and 
reduce  the  amount  of  time  spent  on  board  the  vessel. 

4.  Getting  the  information  on  vessels  in  port  and  vessels  scheduled  to  be  boarded 
in  a  distributed  database  system  allows  for  accurate  real  time  statistics  for 
analysis  at  the  unit,  district  and  headquarters  levels. 

5.  The  consistency  afforded  by  having  a  national  system  for  evaluating  the  risk 
of  vessels  entering  port  is  invaluable.  Ensuring  that  a  vessel  is  evaluated  the 
same  across  all  ports  goes  a  long  way  in  building  the  credibility  of  the 
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program,  since  multiple  boardings  would  be  eliminated  and  vessels  would  be 
handled  the  same  in  different  ports. 

6.  Reducing  the  cycle  time  provides  the  ability  to  raise  the  boarding  ratio  with 
the  same  number  of  personnel  and  thus  reduce  the  chance  that  a  ship  that 
should  be  boarded  will  leave  port  without  being  boarded. 

4.  Disadvantages  and  Limitations 

Some  of  the  disadvantages  and  limitations  to  the  redesign  are  as  follows: 

1.  There  is  a  monetary  cost  to  the  development  of  the  redesign.  The  cost  of 
implementing  the  redesign  in  reality  would  not  be  staggering,  but  due  to  the 
Coast  Guard’s  budgetary  limitations,  cost  becomes  an  issue. 

2.  The  resistance  vessel  agents  may  have  in  changing  the  way  they  do  business 
with  the  Coast  Guard. 

3.  The  resistance  of  ports  that  have  centralized  information  brokers  and  their 
reluctance  to  change  their  business  relationship  with  the  Coast  Guard. 

4.  The  simulation  model’s  limitation  of  not  accounting  for  the  degree  of 
variability  of  personnel  interruptions.  This  may  change  the  actual  cycle  time 
reductions  seen  in  an  actual  implementation  of  the  redesign. 

5.  The  reliance  on  technology  for  the  redesign.  If  the  ability  to  use  the 
technology  is  compromised  by  a  weather  event  etc.,  the  process  could  be 
slowed  down  considerably. 

6.  The  fact  that  the  model  parameters  are  estimations  of  reductions  in  cycle  time 
may  result  in  the  estimations  of  cycle  time  savings  being  different  than  those 
seen  in  an  actual  implementation  of  the  redesigned  process. 

B.  REDESIGN  OF  THE  VESSEL  BOARDING  PROCESS 

1.  Model  and  Description  of  the  Proposed  Process 

Based  on  the  information  provided  by  KOPeR,  and  the  premise  laid  out  for  the 
redesign  of  the  targeting  process,  the  vessel  boarding  process  has  also  been  redesigned. 
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As  with  the  previous  model  above,  I  use  the  model  as  a  guide  to  facilitate  the  discussion 
of  the  redesigned  process  activities.  The  model  of  the  redesigned  vessel  boarding  process 
is  provided  as  Figure  4-5. 


Boarding  Information 
from  Targeting  process 


Figure  4-5.  Vessel  Boarding  Process  Redesign 
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The  redesigned  vessel  boarding  process  begins  where  the  targeting  process  leaves 
pff.  Each  boarding  team  is  equipped  with  a  laptop  computer  with  special  software  and  a 
portable  printer.  The  boarding  teams  download  the  pertinent  vessel  information  from  the 
central  database  to  the  laptop  computer. 

Activity  node  6:  Document  check.  On  board  the  vessel,  the  vessel  information  is 
accessed  on  the  laptop  for  updating.  The  results  of  the  document  check  are  input. 

Activity  node  7:  Physical  inspection.  The  physical  inspection  is  conducted,  and 
the  results  and  documentation  of  the  inspection  are  recorded  on  the  laptop. 

Activity  node  8:  Boarding  complete.  At  the  end  of  the  boarding,  the  boarding 
letter,  with  any  discrepancies,  is  printed  and  left  with  the  Master  of  the  vessel.  If  the 
vessel  is  to  be  detained,  the  appropriate  letters  and  paperwork  to  detain  the  vessel  are 
completed  while  onboard  the  vessel,  then  printed  out  zind  left  with  the  Master. 

Activity  node  9:  Data  synchronization.  Once  back  at  the  office,  the  updated 
information  and  boarding  documentation  are  synchronized  to  the  central  database.  This 
is  accomplished  by  connecting  the  laptop  to  the  office  network  and  running  a 
synchronization  program.  Once  the  information  has  been  uploaded,  an  entry  is  made  in 
the  port  case  review  log  on  the  server  for  the  supervisor  to  check  the  documentation  of 
the  case. 

Activity  node  10:  Boarding  case  reviewed.  The  supervisor  retrieves  the  case 
review  log  that  consists  of  hyperlinks  for  each  of  the  cases  in  question  and  performs  the 
review.  Any  problems  found  are  corrected  on  the  spot,  or  the  supervisor  notifies  the 
boarding  officer  of  the  problems  requiring  correction. 

Activity  node  11:  Boarding  case  filed.  Once  the  review  is  completed,  the 
boarding  information  is  locked  so  further  alterations  cannot  be  made.  This  serves  as  the 
official  documentation  of  that  particular  boarding  of  the  vessel. 

Activity  node  12:  Log  vessel  “no  boards  After  vessels  depart  the  port,  a  list  of 
all  vessels  still  in  port  is  updated  by  a  petty  officer  via  a  web  page. 

As  with  the  targeting  process,  simulation  is  used  for  making  comparisons 
between  the  current  and  redesigned  processes.  Again,  any  parameters,  unless  stated 
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otherwise,  are  derived  from  my  three  years  of  experience  in  directly  performing  and 
supervising  the  process.  Figure  4-6  is  a  portion  of  an  EXTEND+BPR®  simulation 
model  covering  the  current  vessel  boarding  process.  As  with  the  targeting  model,  a 
number  of  assumptions  were  made  during  the  creation  of  this  model  to  simplify  the 
model  as  well  as  to  obtain  meaningful  numbers  for  comparison  between  current  and 
proposed  process  design.  The  assumptions  and  reasons  for  making  them  are  explained 
during  the  discussion  of  the  information  flow  through  the  simulation  model. 


Figure  4-6.  Current  Vessel  Boarding  Process  Simulation  Model 


Step  one  of  this  model  takes  the  vessels  that  need  to  be  boarded  from  the  targeting 
process.  It  should  be  noted  that  the  two  simulation  models  are  integrated.  This  means 
the  vessels  entering  the  vessel  boarding  model  are  those  that  have  been  selected  for 
boarding  by  the  targeting  model.  If  the  targeting  model  does  not  select  any  vessels  to 
board,  the  vessel  boarding  model  does  not  receive  any  input. 

Step  two  is  a  timer  block.  A  timer  is  placed  at  the  beginning  of  the  process  to 
capture  cycle  time. 
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Step  three  is  a  FIFO  queue.  This  block  is  a  holding  area  for  vessel  information  on 
vessels  not  currently  being  boarded.  This  block  is  used  if  the  boarding  team  is  assigned 
more  than  one  boarding. 

Step  four  is  a  transaction  block.  This  block  simulates  the  documentation  check 
carried  out  on  the  vessel.  The  time  delay  for  this  block  is  assumed  to  be  from  a  uniform 
distribution  with  a  minimum  and  maximum  of  ten  and  twenty  minutes  per  vessel, 
respectively.  This  time  delay  takes  into  account  the  varying  amount  of  information  about 
the  vessel  that  needs  to  be  copied. 

Step  four  is  a  decision  block.  This  determines  what  happens  on  the  vessel.  There 
are  three  possible  outcomes  for  the  boarding  of  the  vessel:  no  problems  found, 
discrepancies  found,  and  vessel  detained.  The  decision  is  made  based  on  a  random 
number  with  the  probability  of  vessel  detained  0.05,  discrepancies  found  0.3,  and  no 
problems  found  0.65.  These  probabilities  are  based  on  three  years  of  statistics  kept  at 
MSO  Los  Angeles  -  Long  Beach  (1995-1997)  on  vessel  boardings  conducted  in  that  port. 

Step  five  contains  the  three  possible  outcome  transaction  blocks:  no  problems 
found,  discrepancies  found  and  vessel  detained.  Depending  upon  what  happens  on  the 
vessel,  the  information  will  travel  to  one  of  the  three  possible  outcome  transaction  blocks. 
Each  of  the  blocks  has  a  delay,  that  is  the  amount  of  time  it  would  take  to  account  for  the 
time  spent  on  the  vessel  as  well  as  the  time  required  to  complete  documentation,  review 
and  filing  time.  The  following  assumptions  apply:  The  delay  time  for  the  vessel  detained 
block  is  assumed  to  be  from  a  uniform  distribution  with  a  minimum  and  maximum  of  60 
and  120  minutes.  This  assumption  is  based  on  the  amoimt  of  documentation  required  to 
perform  a  detention,  and  the  extra  amount  of  writing  required  when  there  are 
discrepancies  that  require  a  detention.  Regarding  the  discrepancies  block,  the  delay  time 
is  assumed  to  be  from  a  imiform  distribution  with  a  minimum  and  maximum  of  30  and  60 
minutes.  This  assumption  is  based  on  the  additional  amount  of  writing  and  computer 
data  entry  required  when  there  are  discrepancies  found.  Regarding  the  no  problems 
block,  the  delay  time  is  assumed  to  be  from  a  uniform  distribution  with  a  minimum  and 
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maximum  of  20  and  45  minutes.  This  assumption  is  based  on  the  computer  entry  time 
for  the  documentation  of  the  vessel  boarding. 

Not  pictured  in  Figure  4-6  is  the  final  part  of  the  process  is  the  sixth  step,  which 
deals  with  the  logging  of  vessels  not  boarded  in  the  database.  This  block  is  fed  from  the 
targeting  process  and  has  one  transaction  block,  which  has  a  fixed  delay  time  of  two 
minutes  per  vessel.  This  assumption  holds  because  the  activity  is  a  routine  activity  with 
non-changing  information  requirements. 

The  final  assumption  is  identical  to  the  final  assumption  of  the  targeting  process, 
namely  that  the  personnel  working  on  the  process  are  focused  solely  on  completing  the 
tasks  of  the  process  with  no  interruptions.  Modeling  of  this  type  of  uncertainty  is  not 
needed  for  the  comparison  purposes  of  cycle  time,  but  is  necessary  to  mention,  as  it  is  a 
possible  limitation  of  the  simulation  model.  The  summary  of  parameters  for  this  model  is 
presented  in  Table  4-12. 


Block  Name 

Value/Range 

Fixed/Random 

Distribution 

Copy  Vsl  info 

(10.0, 20.0) 

random 

Real,  Uniform 

What  happens  on  vsl 

(0.0, 1.0) 

random 

Real,  Uniform 

Vsl  Detained 

(60.0, 120.0) 

random 

Real,  Uniform 

Discrepancy(s) 

(30.0, 60.0) 

random 

Real,  Uniform 

No  Problems 

(20.0, 45.0) 

random 

Real,  Uniform 

Log  no  boards 

2 

fixed 

N/A 

Table  4-12.  Current  Vessel  Boarding  Process  Simulation  Model  Parameters 


Measurements  for  this  process  are  taken  in  the  same  manner  as  the  targeting 
process  described  in  Section  B.  The  measurements  for  the  simulation  runs  are  presented 
in  Table  4-13.  Since  the  vessel  boarding  process  takes  the  output  from  the  targeting 
process,  the  number  of  vessels  running  through  the  vessel  boarding  model  vary  based  on 
the  0.25  boarding  ratio  in  the  targeting  process  (the  0.25  boarding  ratio  phenomena  was 
discussed  in  Section  A.I.).  Each  simulation  run  presented  in  Table  4-13  corresponds 
with  the  simulation  nm  of  the  same  number  for  the  targeting  process,  thus  simulating  the 
entire  process  from  beginning  to  end. 
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Sim  # 

1 

2 

3 

4 

7 

8 

9 

10 

Ship  #1 

72.52 

104,49 

47.57 

50.60 

33.32 

35.69 

Ship  #2 

46.33 

44.27 

49.39 

Ship  #3 

138.64 

Ship  #5 

Ship  #6 

Mean: 

72.52 

N/A 

N/A 

N/A 

38.80 

42.54 

72.75 

104.49 

0.00 

0.00 

138.64 

46.33 

0.00 

Std  Dev: 

N/A 

3.01 

N/A 

N/A 

N/A 

Min: 

40.50 

Table  4-13.  Simulation  Delay  Times  for  the  Current  Vessel  Boarding  Process 


The  simulation  model  for  the  redesigned  process  is  identical  to  the  model  for  the 
current  process.  This  is  due  to  the  structure  and  flows  of  the  current  and  redesigned 
processes  being  identical,  thus  the  model  is  unchanged.  The  only  differences  are  the 
delay  times  associated  with  the  transaction  blocks  that  simulate  what  has  happened  on  the 
vessel  during  the  boarding.  The  times  are  to  accoimt  for  the  effort  spent  doing  the 
paperwork  on  the  vessel  and  completing  the  required  documentation  back  at  the  office. 
As  for  the  redesigned  targeting  process,  three  scenarios  were  run:  most  likely,  optimistic 
and  pessimistic.  As  was  done  for  the  targeting  process,  the  parameters  for  the  most  likely 
scenario  were  determined  by  estimating  a  range  of  the  time  saved  for  each  activity.  Based 
off  the  most  likely  scenario  parameters,  high  and  low  limits  for  each  activity  were 
estimated,  thus  providing  the  set  of  parameters  for  the  optimistic  and  pessimistic 
scenarios.  Summaries  of  the  model  parameters  for  the  three  scenario  simulation  runs  are 
provided  as  Tables  4-14,  4-15  and  4-16.  The  results  of  the  simulation  runs  for  the  three 
scenarios  of  the  redesigned  process  are  presented  in  Tables  4-17,  4-18,  and  4-19.  The 
results  were  collected  in  the  same  manner  as  those  for  the  current  simulation  model. 
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Block  Name 

Value/Range 

Fixed/Random 

Distribution 

Copy  vsl  info 

(10.0, 20.0) 

random 

Real,  Uniform 

What  happens  on  vsl 

(0.0, 1.0) 

random 

Real,  Uniform 

Vsl  Detained 

(30.0,  60.0.) 

random 

Real,  Uniform 

Discrepancy(s) 

(15.0, 30.0) 

random 

Real,  Uniform 

No  Problems 

(10.0, 20.0) 

random 

Real,  Uniform 

Log  no  boards 

2 

fixed 

N/A 

Table  4-14.  Redesigned  Vessel  Boarding  Process  Simulation  Mod 

el  Parameters,  Most 

Likely  Scenario 


Block  Name 

Value/Range 

Fixed/Random 

Distribution 

Copy  vsl  info 

o 

O 

o 

random 

Real,  Uniform 

What  happens  on  vsl 

(0.0, 1.0) 

random 

Real,  Uniform 

Vsl  Detained 

random 

Real,  Uniform 

Discrepancy(s) 

(10.0, 15.0) 

random 

Real,  Uniform 

No  Problems 

(5.0, 20.0) 

random 

Real,  Uniform 

Log  no  boards 

2 

fixed 

N/A 

Table  4-15.  Redesigned  Vessel  Boarding  Process  Simulation  Model  Parameters, 

Optimistic  Scenario 


Block  Name 

Value/Range 

Fixed/Random 

Distribution 

Copy  vsl  info 

(15.0,  25.0) 

random 

Real,  Uniform 

What  happens  on  vsl 

(0.0, 1.0) 

random 

Real,  Uniform 

Vsl  Detained 

(40.0,  70.0.) 

random 

Real,  Uniform 

Discrepancy(s) 

(30.0,  35.0) 

random 

Real,  Uniform 

No  Problems 

(15.0,  30.0) 

random 

Real,  Uniform 

Log  no  boards 

2 

fixed 

N/A 

Table  4-16.  Redesigned  Vessel  Boarding  Process  Simulation  Model  Parameters, 


Pessimistic  Scenario 
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Sim# 

1 

2 

3 

4 

5 

6 

mi 

8 

9 

10 

Ship  #1 

39-46 

32.32 

26.55 

30.90 

32.51 

26.96 

25.90 

53.10 

30.40 

Ship  #2 

44.09 

Ship  #3 

30.88 

34.29 

Ship  #4 

36.70 

39.47 

Ship  #5 

29.58 

Ship  #6 

Ship  #7 

Mean: 

N/A 

40.84 

37.49 1 

32.51 

33.97 

38.40 

53.10 

30.40 

Max: 

N/A 

53.46 

69.80 

26.55 

EliBl 

QQ] 

53.10 

30.40 

Min: 

N/A 

26.55 

■cWliM 

30.40 

Std  Dev: 

N/A 

9.33 

N/A 

N/A 

Totafs: 

Mean: 

38.37 

Max: 

69.80 

Min: 

Table  4-17.  Simulation  Delay  Times  for  the  Redesigned  Vessel  Boarding  Process,  Most 

Likely  Scenario 


Sim# 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Ship  #1 

24.73 

13.35 

17.51 

20.96 

18.76 

Ship  #2 

24.76 

29.23 

28.86 

25.34 

Ship  #3 

28.11 

31.85 

Ship  #4 

36.13 

Ship  #5 

16.18 

Ship  #6 

Ship  #7 

Mean: 

24.73 

N/A 

20.96 

23.81 

N/A 

Max: 

24.73 

24.76 

N/A 

36.13 

N/A 

20.96 

28.86 

N/A 

Min: 

24.73 

13.35 

N/A 

17.51 

N/A 

20.96 

18.76 

N/A 

Std  Dev: 

N/A 

5.75 

N/A 

7.69 

N/A 

N/A 

7.14 

N/A 

N/A 

3.41 

Totals: 

Max: 

36.13 

Min: 

16.18 

Table  4-18.  Simulation  Delay  Times  for  the  Redesigned  Vessel  Boarding  Process, 

Optimistic  Scenario 
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Sim# 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Ship  #1 

49.51 

lESEi! 

43.91 

41.20 

30.40 

Ship  #2 

65.29 

60.30 

bh 

Ship  #3 

51.25 

46.17 

48.81 

50.03 

Ship  #4 

60.87 

65.20 

Ship  #5 

Ship  #6 

Ship  #7 

50.02 

46.23 

51.79 

57.09 

41.20 

30.40 

Max: 

65.29 

60.30 

41.20 

30-40 

Min: 

49.51 

39.74 

46.23 

35.54 

43.91 

41.20 

30.40 

Std  Dev: 

8.65 

14.54 

N/A 

13.43 

12.73 

N/A 

N/A 

Totals: 

Mean: 

53.40 

Max: 

92.48 

Min: 

46.17 

SDev: 

14.56 

Table  4-19.  Simulation  Delay  Times  for  the  Redesigned  Vessel  Boarding  Process, 


Pessimistic  Scenario 


2.  Comparison  Against  the  Current  Process 

The  redesigned  process  looks  much  like  the  current  process  with  the  exception  of 
the  addition  of  technology  to  remove  and  streamline  some  activities.  While  the  changes 
to  the  process  are  not  as  radical  as  those  proposed  for  the  targeting  process,  the  changes 
nevertheless  promise  to  improve  the  process  significantly  by  using  automation  to  remove 
redundant  cop3dng  of  data  and  removing  lost  time  in  the  documentation  activities. 

The  redesigned  process  has  lost  the  filing  activity  the  current  process  has,  since  all 
of  the  official  documentation  is  now  kept  electronically.  This  makes  the  process  one 
activity  shorter  than  the  current  process. 

Table  4-20  presents  a  comparison  of  the  current  and  redesigned  process 
configuration  measurements.  The  configuration  measurements  were  discussed  and 
defined  in  Chapter  III. 
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Configuration  Measure 

Current  Process  Value 

Redesigned  Process  Value 

Process  Size 

8 

6 

Process  Length 

8 

6 

Handoffs 

3 

1 

Feedback  loops 

1 

1 

IT-Support 

2 

6 

IT-Communication 

0 

6 

IT-Automation 

0 

3 

Table  4-20.  Comparison  of  Configuration  Measures 


There  are  two  items  to  note  concerning  the  redesigned  process  values  in  Table  4- 
20.  First,  the  process  length  is  six;  this  is  the  result  of  removing  the  compilation  of  the 
vessel  boarding  documentation  activity  of  the  current  process  (see  Figure  4-5)  and 
considering  the  final  activity  a  process  unto  itself  The  second  item  to  note  is  the  dramatic 
increase  in  IT  support,  IT  communication  and  IT  automation.  These  items  are  the  result 
of  the  application  of  technology  to  the  process. 

To  further  compare  the  two  processes,  as  done  for  the  targeting  process,  the 
configuration  measures  in  Table  4-20  are  given  to  KOPeR  for  redesign  diagnosis.  The 
resulting  diagnosis  is  shown  in  Table  4-21  along  with  the  diagnosis  for  the  current  vessel 
boarding  process. 


Measure  Name 

(Numeric)  -  Diagnosis 

Current  Process 

Redesigned  Process 

Parallelism 

(1.0)  -  sequential  process 

(1.0)  —  sequential  process 

Handoffs  fraction 

(0.375)  -  process  fiiction 

(0.167)  -  handoffs  look  OK 

Feedback  fraction 

(0.125)  -  feedback  looks  OK 

(0. 167)  -  feedback  looks  OK 

IT  support  fi-action 

(0.25)  -  inadequate  IT  support 

(1.0)  -  IT  support  looks  OK 

IT  communication 
fraction 

(0.0)  -  inadequate  IT 
communications 

(1.0)  -  IT  communication 
looks  OK 

IT  automation 
fraction 

(0.0)  -  IT  automation  first 
requires  substantial 
infrastructure  in  terms  of 
support  and  communication. 

(0.5)  -  IT  automation  looks 

OK 

Table  4-2 1 .  Comparison  of  Diagnoses 


In  the  areas  of  parallelism  and  feedback,  the  diagnosis  does  not  show  any 
difference  between  the  current  and  redesigned  processes.  Parallelism  shows  no 
improvement,  this  is  due  to  the  decision,  based  on  arguments  made  in  Chapter  III,  to 
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leave  the  process  sequential.  Feedback  shows  no  difference  because  the  number  of 
feedback  loops  in  the  process  were  not  changed.  The  diagnosis  for  handoffs  has  gone 
from  process  friction  to  OK.  The  diagnosis  for  IT  support,  IT  communication  and  IT 
automation  have  gone  from  inadequate  to  OK.  Therefore,  the  redesign  has  succeeded  in 
eliminating  these  last  four  negative  diagnoses. 

The  largest  differences  from  the  current  process  lie  in  the  area  of  the  critical 
performance  measures  for  the  redesign.  The  average  simulation  cycle  time  for  the 
current  process  is  59.6  minutes,  whereas  the  most  likely  scenario,  has  a  cycle  time  of  38.4 
minutes  per  vessel.  This  constitutes  a  reduction  in  cycle  time  of  21.2  minutes  per  vessel,  a 
reduction  of  35.6%.  For  the  optimistic  scenario,  the  cycle  time  is  23.9  minutes  per  vessel. 
This  reduces  the  cycle  time  by  35.7  minutes  per  vessel,  a  59.9%  reduction.  For  the 
pessimistic  scenario,  the  cycle  time  is  53.4  minutes  per  vessel.  This  is  a  slight  decrease  in 
cycle  time  of  6.2  minutes  per  vessel,  or  a  10.4%  reduction.  A  summary  of  the  cycle 
times,  savings  and  percent  reductions  is  provided  as  Table  4-22. 


Scenario 

Cycle  Time 

Reduction 

%  Reduction 

Man  Years  Saved 

Current 

59.6  min 

N/A 

N/A 

N/A 

Optimistic 

23.9  min 

35.7  min 

59.9% 

2.3 

Most  Likely 

38.4  min 

21.2  min 

35.6% 

1.4 

Pessimistic 

53.4  min 

6.2  min 

10.4% 

0.4 

Table  4-22.  Summary  of  Cycle  Time  Savings  by  Scenario 


As  shown  with  the  vessel  targeting  process,  aggregating  the  numbers  over  the  11 
ports  that  have  large  PSC  programs  provides  an  idea  of  the  amount  of  time  saved 
annually  by  the  redesigned  process.  Based  on  the  simulation,  the  average  number  of 
vessel  boardings  a  day  per  port  is  two.  Assuming  2  vessel  boardings  a  day  per  port  and  a 
boarding  ratio  of  0.25,  the  time  saved  would  be:  2837.3  hours  per  year  for  the  most 
likely  scenario;  4777.9  hours  per  year  for  the  optimistic  scenario;  and  829.8  hours  per 
year  for  the  pessimistic  scenario.  (The  hours  per  year  were  calculated  with  the  following 
formula:  total  number  hours  saved  yearly  =  minutes  saved  X  number  of  vessels  X  (365 
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days  in  a  year  60  minutes)  X  1 1  ports)  This  equates  to  approximately  1 .4  man-years 
saved  for  the  most  likely  scenario,  2.3  man-years  for  the  optimistic  scenario,  and  0.4 
man-years  for  the  pessimistic  scenario,  and  only  for  the  11  ports  with  large  PSC 
programs. 

With  respect  to  the  critical  performance  measure  of  data  transcription,  the  number 
of  times  data  are  transcribed  for  the  redesigned  process  is  zero  compared  to  four  for  the 
current  process.  This  is  a  particularly  telling  number  in  that  there  is  no  information  being 
copied  repeatedly  as  it  is  in  the  current  process.  Thus,  the  data  going  into  the  process  will 
be  more  accurate  and  timely.  The  combination  of  the  number  of  transcriptions,  and  the 
fact  that  the  documentation  is  done  onboard  the  vessel,  as  opposed  to  doing  the 
documentation  later,  leads  to  a  much  improved  process  in  terms  of  accuracy  and 
timeliness. 

In  the  area  of  technology,  the  redesigned  process  is  much  more  technology 
enabled  than  the  current  process.  Where  the  current  process  requires  pen  and  pencil 
record  keeping  and  rudimentary  use  of  a  database,  the  redesigned  process  relies  on  web 
pages,  a  database  and  electronic  record  keeping.  Documenting  the  boarding  in  the 
current  process  is  a  task  that  is  not  completed  at  one  time;  rather,  part  is  done  onboard  the 
vessel,  and  the  final  docmnentation  is  done  in  the  office.  The  completion  of  the 
documentation  can,  at  times,  take  place  two  or  three  days  after  the  vessel  boarding, 
especially  if  the  vessel  is  detained.  In  the  redesigned  process,  the  documentation  of  the 
boarding  is  completed  onboard  the  vessel.  This  includes  any  required  paperwork  to 
detain  the  vessel. 

3.  Advantages  of  the  Proposed  Process 

The  redesigned  process  has  many  advantages  over  the  cmrent  process.  These 
advantages  are  as  follows: 

1.  The  reductions  in  cycle  time  and  number  of  transcriptions,  which  were  shown 
in  the  previous  section,  are  the  most  significant.  Reducing  the  cycle  time  on 
the  process  allows  for  more  timely  documentation  of  the  boarding,  which 
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leads  to  the  elimination  of  redundant  boardings  by  other  MSOs.  Additionally, 
the  time  saved  allows  for  a  reduction  in  manpower,  as  fewer  boarding  teams 
need  to  be  fielded  to  perform  the  same  number  of  vessel  boardings. 

2.  The  improvement  in  accuracy  by  reducing  the  number  of  transcriptions  allows 
for  less  rework  and  time  spent  by  the  supervisor  in  reviewing  the  case  work. 
This  gives  the  supervisor  more  time  to  perform  other  duties.  The  boarding 
officer  also  benefits  from  the  improved  accuracy  by  not  having  to  rework 
errors  made  in  the  case.  Overall,  the  morale  of  the  personnel  performing  the 
process  will  likely  improve,  because  there  will  be  less  time  spent  on  the 
paperwork  and  more  time  spent  on  training  and  doing  the  job  at  hand. 

3.  Completing  the  documentation  on  a  laptop  computer  and  synchronizing  with 
the  main  database  provides  immediate  access  to  the  documentation  of  the 
vessel  boarding.  With  the  documentation  available  immediately,  any 
questions  on  what  happened  on  the  boarding  can  be  immediately  accessed 
without  having  to  shuffle  through  papers  or  hunt  down  the  boarding  officer  for 
details. 

4.  Having  a  nationwide  standard  for  the  completion  of  vessel  boarding 
documentation  reduces  the  “learning  curve”  for  boarding  officers  reassigned 
to  another  unit,  as  the  process  will  be  the  same  everywhere.  Additionally,  the 
consistency  of  the  documentation  will  allow  for  direct  comparisons  of  unit 
performance  of  the  PSC  process. 

5.  The  filing  of  the  case  work  electronically  saves  on  office  space  for  filing 
cabinets,  and  reduces  the  burden  of  keeping  track  of  the  archival  process  for 
federal  records.  Since  the  official  records  are  kept  on  the  database  server  at  a 
centralized  location,  the  use  of  regular  backups  and  automated  archival  allows 
this  process  to  be  performed  in  a  single  location  with  a  large  reduction  in 
manpower  to  complete  the  process. 
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4.  Disadvantages  and  Limitations 

There  are  a  number  of  disadvantages  and  limitations  to  the  redesigned  vessel 
boarding  process,  they  are  as  follows: 

1.  The  large  cost  involved  in  providing  portable  computers  and  printers  to  all 
MSOs  that  perform  the  PSC  process. 

2.  The  cost  of  developing  the  software  to  implement  the  system,  while  not 
staggering,  is  a  concern  considering  the  Coast  Guards  limited  budget. 

3.  The  simulation  model’s  limitation  of  not  accounting  for  the  degree  of 
variability  of  personnel  interruptions.  This  may  change  the  actual  cycle  time 
reductions  seen  in  an  actual  implementation  of  the  redesign. 

4.  There  may  be  resistance  among  the  boarding  officers  in  using  portable 
computers  to  document  the  vessel  boardings;  especially  among  the  older 
personnel  who  are  not  as  comfortable  using  computers. 

5.  The  loss  of  a  portable  computer  would  result  in  the  loss  of  the  entire  record  of 
the  vessel  boarding.  While  not  a  common  occurrence,  the  loss  of  equipment 
while  boarding  a  vessel  off  shore  does  occur. 

6.  There  may  be  resistance,  by  persormel  who  want  to  keep  paper  records  of  the 
boardings  locally.  This  would  negate  the  savings  of  office  space  for  filing 
cabinets. 

C.  MERGING  OF  THE  TWO  PROCESSES 

Since  the  entire  process  was  split  into  two  separate  parts,  the  targeting  process  and 
the  vessel  boarding  process,  for  the  redesign,  the  integration  of  the  two  parts  needs  to  be 
addressed.  The  links  between  the  two  processes  are  the  list  of  the  vessels  identified  for 
boarding  and  the  list  of  vessels  due  in  port.  These  two  pieces  of  information  are  required 
for  the  vessel  boarding  process  to  start  and  complete. 

While  partially  addressed  by  the  description  of  the  redesigns,  it  is  important  to 
understand  this  linkage.  At  the  completion  of  the  targeting  process,  there  are  two  lists  of 
vessels;  one  is  the  list  of  vessels  to  be  boarded,  and  the  other  is  the  list  of  vessels  due  into 
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port.  Both  of  these  lists  are  stored  on  the  database  server  for  each  port  in  the  nation. 
When  a  boarding  team  has  been  assigned  a  vessel  to  board,  the  boarding  officer  uses  a 
laptop  computer  to  load  the  pertinent  vessel  information  into  a  local  database  on  the 
computer.  This  is  the  linkage  between  the  two  processes. 

For  the  entire  PSC  process  to  be  complete,  the  list  of  vessels  in  port  has  to  be 
updated  when  vessels  leave  the  port.  Since  this  list  is  stored  on  the  database  server,  it  is 
only  a  matter  of  accessing  the  list  on  a  web  page,  and  updating  the  status  of  the  vessels. 
This  completes  the  PSC  process. 

D.  SUMMARY 

In  this  chapter,  two  processes,  the  targeting  process  and  the  vessel  boarding 
process,  have  been  redesigned  based  on  the  recommendations  of  Chapter  III.  In  addition 
to  the  redesign,  simulation  was  used  to  compare  the  possible  reductions  in  critical 
performance  measures  between  the  current  and  proposed  processes  using  three  scenarios; 
most  likely,  optimistic  and  pessimistic. 

In  the  next  chapter,  a  proof  of  concept  prototype  is  developed  to  test  the 
technology  of  the  redesign  in  this  chapter.  It  consists  of  the  development  of  a  database,  a 
decision  support  fimction,  web  pages  to  support  interaction  with  the  database,  and  an 
application  to  support  the  remote  use  of  the  database  on  board  a  vessel. 
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V.  IMPLEMENTATION 


This  chapter  describes  the  development  and  implementation  of  a  proof  of  concept 
prototype  of  the  redesigned  process.  To  see  how  the  redesigned  process  will  actually 
operate,  a  prototype  implementation  of  the  process  has  been  developed  to  establish  proof 
of  concept.  Table  5-1  provides  a  listing  of  the  tools  used  in  creating  and  running  the 
prototype  called  RePortS  (for  Re-engineered  Port  System).  The  actual  implementation  of 
the  full  system,  by  a  team  of  professional  software  engineers,  will  be  more  polished  and 
use  more  “industrial  strength”  tools  than  those  used  here. 


Tool  Name 

Purpose 

Development 

and 

Deployment 

tools 

Create  Data  Flow  Diagrams 

SALSA 

Create  Semantic  Object  Model 

Microsoft  Access 
97 

Provide  the  back  end  database  and  portable 
application  and  database 

Evrsoft  Page 
2000 

Build  the  web  pages  for  the  web  based  portion  of  the 
application 

Microsoft  Internet 
Information 

Server  4.0  (IIS) 

Provide  HTTP  service  and  active  server  page 
rendering  of  the  web  pages  and  data  from  the 
database. 

Microsoft  Internet 
Explorer  5.0 

Used  to  test  the  application. 

Table  5-1.  Tools  Used  to  Implement  RePortS 

To  assist  in  the  completion  of  RePortS,  a  Rapid  Application  Development  (RAD) 
systems  development  methodology  is  used.  This  approach  provides  a  quick  way  to 
develop  a  system  compared  to  traditional  methods  (Hoffer  1999,  p.492),  and  therefore  is 
particularly  appropriate  for  prototype  development.  The  RAD  life  cycle  has  four  phases: 
requirements,  design,  construction  and  roll  out. 
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A.  REPORTS  PROTOTYPE  REQUIREMENTS  AND  DESIGN 

The  first  step  of  the  process  is  to  identify  the  requirements  for  RePortS.  To  this 
end,  the  requirements  for  the  system  are  derived  from  the  description  of  the  process 
provided  in  Chapter  IV.  These  requirements  in  broad  terms  are  as  follow: 

1 .  The  system  will  have  a  database. 

2.  The  database  will  be  accessible  via  the  Intemet/Intranet. 

3.  The  system  will  interact  with  external  entities  as  well  as  entities  internal  to  the 
Coast  Guard. 

4.  The  system  will  have  a  decision  support  function. 

5.  There  will  be  a  capability  to  update  the  main  database  from  a  portable 
database. 

6.  Hard  copy  documentation  will  be  created  from  a  portable  computer  as  well  as 
a  computer  connected  to  the  Intemet/Intranet. 

7.  All  review  functions  will  occur  online. 

While  these  requirements  are  general  in  nature,  the  intent  of  the  RAD  approach  is  to 
allow  the  user  to  assist  in  the  development  process  and  identify  requirements  as  the 
development  proceeds.  Since  the  user  and  developer  of  the  system  are  the  same  person  in 
this  case,  the  identification  of  additional  requirements  proceeds  with  the  development  of 
the  system.  It  should  be  noted  that  the  primary  motivation  for  development  of  RePortS  is 
to  show  that  the  redesign  of  the  process  is  feasible,  not  to  fully  implement  all  features  that 
an  actual  implementation  of  the  process  would  require. 

The  next  step  of  the  RAD  approach  is  design.  In  the  design  phase,  the 
requirements  and  user  input  are  transformed  into  a  data  model  and  a  process  model. 
These  models,  shown  below,  not  only  document  the  requirements,  but  also  assist  the 
developer  to  understand  the  requirements  better. 

1.  Database  Design:  Conceptual  Model 

The  technique  used  to  create  the  data  model  is  the  semantic  object  model  (SOM). 
The  SOM  uses  semantic  objects  to  represent  identifiable  things  in  the  users’  work 
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enviromnent.  More  formally,  a  semantic  object  is  a  named  collection  of  attributes  that 
sufficiently  describes  a  distinct  identity.  (Kroenke  1998,  p72)  For  this  prototype,  the 
original  intention  was  to  use  the  data  model  for  the  MSN  project.  However,  it  has  not 
been  possible  to  acquire  a  copy,  or  even  to  ascertain  if  one  actually  exists.  Therefore,  I 
have  created  a  SOM  based  on  the  information  needed  to  successfully  build  the  prototype 
as  shown  in  Figure  5-1. 


o  %m  M 
S)  Ih/IONumber  m 
0  VslName  m 
0  BldDale  t-i 
0  SpecialNole  0-1 
0  VsIType  m 
0  Length  vt 
0  Breadth  m 
0  Depth  M 
0  Propulsion  m 
[Boarding  |o.n 
IE  IlntParty  1 1.3 
IE  |Class  1 1-1 
[FlagState  I  m 
IE  I  Certificate  Iq-n 


[E  BoanfingOfficer 


0  iCBOID  M 
0  BO Name  m 
0  Rank  m 
0  Qua!  M 
0  QualDate  m 
m  [Boarding  |d-n 
H]  [Poft  |i-i _ 


EE  Boarffing 


0  JCaseNum  m 
0  Type  t.i 
0  T  Points  M 
O  Priority  i.t 
0  ArrivalDate 
0  BdingDate  i-i 
0  BdingPlace  m 
0  DateClosed  m 
0  Detained  0-1 
0  OpControlo-i 
0  InProco-i 
0  Closed  t-i 
0  Details  i-t 
0  BoardingTime  m 
mjDiTlo-N 
EE  [Vessel  |  t-i 
EE  [BoardingOfficer  1 1.4 
[H  jPorf  |m 
[EfDirTlo.N 
EE  [IntParty  |m 


!ECias« 


0  JCIassID  i-t 
0  ClassCode  m 
0  ClassName  m 
°Q  Address  ].] 


0  Street 
0  City  0-1 
0  State  0-1 
0  Country  o-t 
0  Zip  0-1 

0  Phone  Number  i.t 
0  T  Points  10 
IE  [Vessel  [q-n 


IE  Certified 


$LertlD  }.i  ^ 


m\ 

0  $CertType  t-i 
0  IssuedBy  m 
0  IssueDate  t-t 
0  EndorseDate  m 
0  ExpireDate  1.1 
0  Issuedr^.!  1.1 


!E  Fla^late 


0  JFIagID  m 
0  Country  Code  m 
0  Country  Name  m 


oa  .Address  m  ^7 


0  Street  0-1 
0  City  0-1 
0  State  0-1 
0  Zip  0-1 

0  Phone  Number  m 
0  TPoints  M 
IE  [Vessel  [q-n 


IE  intPaity 


0  ^JPartylD  m 
0  PartyName  t.| 
0  PartyRole  m 


Address  vt 


0  Street  o-t 
0  City  0-1 
0  State  0-1 
0  Country  o-t 

0  Zip  0-1 

0  Phone  Number  m 
0  TPoints  i.t 
IE  [Vessel  [q.n 
EE  [Boarding  [q-n 


0  Street  0-1 
0  City  0-1 
0  Slate  0-1 
0  Zip  0-1 

0  Phone  Number  i.t 
0  Email  m 
EE  [Boarding  [p.^ 

IE  [BoardingOfficer  I Q.N 
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iHDeflD  M  ^ 
0  SOefNum  m 
IE  [Boarding  I  j.t 
0  DefType  1.1 
0  DefCode  m 
0  FixBy  i-t 
0  Problem  m 
0  DateClosed  m 
0  Closed  i-t 

0  Resolution  m 
E  [Boardingl  M 


Figure  5-1.  Semantic  Object  Model  for  RePortS 


The  conventions  used  in  the  SOM  by  Salsa  are  explained  below.  Each  object  is 
shown  as  a  rectangle  with  the  name  of  the  object  on  the  top.  Each  object  has  a  list  of 
attributes  listed  in  the  window  of  the  object.  The  key  field(s)  of  an  object  is  (are)  denoted 
by  two  asterisks  stacked  on  top  of  each  other.  Attribute  cardinalities  are  given  next  to 


each  attribute,  (e.g.,  VslNamei.i,  where  the  m  is  the  cardinality  of  the  attribute 
VslName).  The  cardinality  is  denoted  as  minimum  and  maximum  cardinality  from  left  to 
right,  so  in  the  above  example  the  minimum  number  of  instances  of  VslName  in  the 
record  is  one,  and  the  maximum  instance  is  also  one.  To  represent  a  many  relationship, 
the  symbol  “N”  is  used.  A  table’s  relationship  with  another  table  is  denoted  by  listing  the 
related  table  name  in  the  list  of  attributes  with  a  box  aroimd  it,  (i.e..  Boarding  o-n)  with 
the  cardinalities  used  in  the  same  manner  as  described  above. 

Each  of  the  objects  in  the  SOM  is  defined  and  described: 

1.  The  Vessel  object  is  designed  to  capture  the  data  pertinent  to  a  vessel.  It  has 
the  attributes  that  describe  a  vessel  which  can  have  a  boarding  done  on  it.  A 
vessel  can  have  up  to  three  Interested  Parties;  the  owner,  operator,  and  agent. 
Additionally,  a  vessel  can  have  only  one  Class  and  Flag  State,  but  may  have 
many  Certificates. 

2.  The  Boarding  object  is  used  to  capture  the  information  from  a  physical 
inspection  of  a  vessel.  It  captures  the  where,  what  kind,  when,  etc. 
dimensions  of  the  boarding.  Additionally,  it  captures  the  grading  information 
on  a  vessel  for  a  port  call.  A  boarding  may  have  many  deficiencies 
(represented  by  a  Def  object),  and  may  only  be  done  on  one  vessel.  A 
boarding  is  performed  by  one  to  four  boarding  officers  in  only  one  port.  A 
boarding  also  has  only  one  interested  party  who  is  the  agent  for  the  vessel. 

3.  The  Def  object  is  a  deficiency  found  during  a  particular  boarding  on  a 
particular  vessel.  It  contains  the  information  needed  to  describe  the  nature  of 
the  discrepancy  as  well  as  the  requirements  needed  to  repair  the  problem  and 
resolve  the  discrepancy  (i.e.,  have  it  marked  as  closed  in  the  database).  The 
deficiency  is  only  identified  on  one  boarding  and  when  cleared,  it  becomes 
related  to  the  boarding  that  cleared  the  deficiency. 

4.  The  Certificate  object  captures  the  information  contained  on  the  certificates 
issued  to  a  vessel.  This  object  has  issue,  endorse,  and  expiration  dates,  as  well 
as  who  issued  the  certificate.  Each  certificate  is  issued  only  to  one  vessel. 


5.  The  Class  object  represents  the  classification  society  of  the  vessel.  The  name 
of  the  classification  society,  contact  information  and  targeting  points  are  the 
items  captured  by  this  object.  A  classification  society  can  class  many 
different  vessels. 

6.  The  IntParty  object  represents  the  owners,  operators,  agents,  and  any  other 
party  that  has  an  interest  in  the  vessel.  Like  the  Class  object,  it  contains  the 
contact  information  for  the  party  it  represents,  and  the  targeting  points  for  the 
particular  party.  An  interested  party  can  be  associated  with  many  different 
vessels  and  boardings. 

7.  The  FlagState  object  represents  the  country  of  registry  of  the  vessel.  It 
contains  the  contact  information  for  the  Flag  State’s  maritime  attache,  and  the 
targeting  points  for  each  Flag  State.  A  Flag  State  can  have  many  vessels  in  its 
vessel  registry. 

8.  The  Port  object  represents  the  Coast  Guard  unit  covering  a  particular  port 
area.  It  contains  the  name  of  the  unit  and  contact  information.  A  port  has 
many  boarding  officers,  and  many  boardings  may  be  conducted  in  the  port. 

9.  The  BoardingOfficer  object  represents  the  boarding  officers  performing 
boardings  on  the  vessels.  The  name  of  the  boarding  officer,  qualifications, 
current  unit,  and  other  identifying  information  are  contained  in  the 
BoardingOfficer  object.  A  boarding  officer  performs  many  boardings,  but  is 
associated  with  only  one  port. 

2.  Database  Design:  Relational  Model 

The  next  step  in  database  design  is  to  transform  the  SOM  into  relational  tables  in 
a  database,  which  requires  a  three-step  procedure. 

1.  Transform  the  object  diagrams  into  relations.  The  relations  take  the  form  of 
the  relation  name  with  the  key  field  of  the  relation  followed  by  the  attributes. 

2.  Normalize  relations  to  remove  modification  anomalies,  such  as  insertion  and 
deletion  anomalies. 
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3.  Transform  the  normalized  relations  into  a  table  definition,  which  can  be 
incorporated  into  the  database  schema.  The  schema  defines  the  database’s 
structure,  tables,  relationships,  domains  and  business  rules.  (Kroenke  1998,  p. 
30)  From  the  schema,  the  physical  database  can  then  be  created. 

Based  on  the  SOM  in  Figure  5-1,  the  data  model  is  transformed  into  relations  by 
using  the  transformation  methodology  suggested  by  Kroenke.  (Kroenke  1998,  pp.  163- 
185)  In  this  methodology,  each  semantic  object  is  mapped  into  one  or  more  relations. 
Relational  notation  is  different  from  that  for  the  SOM.  The  key  field  for  each  table  is 
underlined  and  foreign  keys  from  other  tables,  that  are  used  to  create  a  relationship  with 
those  tables,  are  denoted  with  a  “_FK”  after  the  name  of  the  attribute.  Table  5-2  shows 
the  relations  created  by  this  process. 

With  the  transformation  complete,  the  resulting  relations  need  to  be  normalized  to 
prevent  any  relational  anomalies,  discussed  previously,  from  occurring.  The  classes  of 
relations,  and  the  techniques  for  preventing  the  anomalies  are  called  normal  forms. 
(Kroenke  1998,  p.ll7)  There  are  several  classes  of  normal  form;  however,  this 
implementation  will  be  normalized  only  to  second  normal  form.  Using  second  normal 
form  affords  a  good  tradeoff  between  anomaly  reduction  and  simplicity  in  relational 
database  design.  This  is  an  appropriate  balance  for  a  prototype  that  will  not  be  used  in  a 
production  environment  where  a  more  normalized  form  would  provide  benefits  from  a 
greater  reduction  of  deletion  anomalies.  A  relation  is  in  second  normal  form  when  all  of 
its  non-key  attributes  are  functionally  dependent  on  all,  and  not  just  a  subset  of,  the  key 
attributes.  Another  test  of  second  normal  form  is  to  have  single  attribute  keys.  (Kroenke 
1998,  p.ll8)  Analyzing  the  relations  in  Table  5-2  reveals  the  relations  are  already  in 
second  normal  form.  All  but  five  of  the  relations  have  single  key  attributes,  two  relations 
with  multiple  attribute  keys  have  no  other  attributes,  and  in  the  other  relations,  each  non¬ 
key  attribute  depends  upon  all  of  the  key  attributes  (in  order  to  access  any  of  the 
attributes,  both  parts  of  the  relation  key  are  needed). 
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Table 

Attributes 

VESSEL 

Vin,  IMONumber,  VslName,  SpecialNote,  VslType,  BldDate, 

Length,  Breadth,  Depth,  Propulsion,  ClassID_FK,  FlagID_FK 

BOARDING 

CaseNum,  Type,  ArrivalDate,  Tpoints,  Priority,  InProc, 

BdngDate,  BdngPlace,  Detained,  OpControl,  DateClosed, 

Closed,  Details,  BoardingTime,  Vin_FK,  PortID_FK, 

PartyIDFK 

CLASS 

ClassID,  ClassCode,  ClassName,  Street,  City,  State,  Country, 

Zip,  TPoints,  PhoneNo 

INTPARTY 

PartylD,  PartyName,  PartyRole,  Street,  City,  State,  Country, 

Zip,  TPoints,  PhoneNo 

DEF 

DeflD,  CaseNum  FK,  DefType,  DefCode,  FixBy,  Problem, 

DateClosed,  Closed 

FLAGSTATE 

FlagDD.  CountryCode,  CountryName,  Street,  City,  State,  Zip, 

TPoints,  PhoneNo 

VESSEL-INTPARTY 

Vin  FK,  PartylD  FK 

CERTIFICATE 

CertType,  Vin  FK,  IssuedBy,  IsuueDate,  EndorseDate, 

ExpireDate,  IssuedAt 

BOARDING  OFFICER 

BOID,  BOName,  Rank,  Oual,  OualDate,  PortID  FK 

PORT 

PortID,  UnitName,  Street,  City,  State,  Zip,  PhoneNo,  Email 

BOARDING¬ 
BOARDING  OFFICER 

CaseNum  FK.  BOID  FK 

DEFRES 

DefID  FK,  CaseNum  FK,  Resolution,  CaseNumRes  FK 

Table  5-2.  RePortS  Relations 


The  table  definition  now  follows  the  transformation  to  relations  and 
normalization.  Appendix  B  contains  the  table  definition  for  the  relations  presented  in 
Table  5-2.  The  table  definition  contains  the  table  names,  their  attributes,  key  and  foreign 
key  fields,  and  the  type  and  size  of  all  attributes.  With  the  information  contained  in  the 
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table  definition  and  relations,  there  is  enough  information  in  the  schema  to  create  the 
database. 

An  area  not  represented  in  the  database  schema  is  that  of  the  business  rules. 
Business  rules  specify  the  constraints  on  allowed  data  values  that  must  be  enforced. 
These  constraints  are  enforced  by  the  database  and  the  applications  that  interact  with  the 
database  and/or  the  users  of  the  database.  (Kroenke  1998,  p.32)  A  large  number  of  the 
rules  for  data  are  captured  in  the  SOM,  for  example,  a  vessel  can  have  one  and  only  one 
Flag  State.  The  business  rules  not  identified  by  cardinalities  or  in  other  areas  of  the 
schema  are  identified  as  follows: 

1 .  When  a  vessel  arrival  is  entered,  a  boarding  is  created  for  the  vessel  arrival. 

2.  Using  any  type  of  boarding  can  clear  deficiencies. 

These  business  rules  will  be  enforced  in  the  application  interface  with  the  database. 

3.  Process  Design:  Data  Flow  Diagram  (DFD) 

Another  model  commonly  used  to  assist  in  the  development  of  systems  is  the  data 
flow  diagram  (DFD).  A  DFD  provides  a  picture  of  the  movement  of  data  between 
external  entities  and  the  processes  and  data  stores  within  a  system.  (Hoffer  1999,  p278) 
DFDs  are  composed  from  four  different  symbols:  the  process,  data  store,  source/sink  and 
data  flow.  A  sample  of  each  type  of  symbol  is  shovra  in  Figure  5-2. 


r  ^ 

I  Source/Sink 

Process 

i 

L _ J 

r 

Data  Flow 

[ 

Data  Store 

Figure  5-2.  DFD  Symbols 
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An  explanation  of  each  of  the  symbols  is  provided  for  those  unfamiliar  with  the 
DFD  modeling  approach.  The  process  is  work  or  action  performed  on  data  to  transform, 
store  or  distribute  it.  The  data  store  is  data  at  rest;  it  is  stored  in  some  sort  of  media,  be  it 
a  folder  or  a  database.  The  source/sink  is  the  origin  or  destination  of  the  data,  often 
referred  to  as  an  external  entity.  The  data  flow  is  the  movement  of  data  between  two 
points  in  the  system.  Typically,  the  data  flow  is  labeled  with  the  type  of  data  moving 
along  that  data  flow.  (Hoffer  1999,  pp.280-281) 

A  DFD  for  RePortS  (Figure  5-3)  has  been  built  to  better  identify  the  flows  of  data 
and  the  different  processes  needed  to  implement  the  prototype.  The  DFD  shows  the 
different  entities  that  interact  with  the  system,  the  data  stores  in  the  system  and  the 
different  processes  that  act  on  the  data. 


Figure  5-3.  DFD  for  the  RePortS  Prototype 
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As  seen  in  Figure  5-3,  there  are  nine  distinct  processes  that  act  on  the  data  either 
provided  by  the  sources/sinks  or  drawn  from  the  data  stores.  These  nine  processes  will 
be  the  focus  of  the  prototype  development  efforts.  All  but  one  of  the  processes  represent 
web  pages  and  code  associated  with  the  transformation  and  delivery  of  data  from  the  data 
stores.  The  other  process,  5.0  Update  Vessel  Data,  represents  the  interface  on  the 
portable  database  for  use  onboard  a  vessel.  It  is  vital  to  understand  the  data  flows  into  and 
out  of  each  of  the  processes;  therefore,  each  of  the  processes  is  described  along  with  its 
respective  inputs  and  outputs: 

1.  The  Log  Vessel  Arrival  process  is  the  transformation  of  the  vessel  arrival 
information  provided  by  the  Vessel  Agent  into  a  vessel  boarding  and  grading 
result,  which  then  gets  stored  in  the  MSN  data  store. 

2.  The  Vessel  Arrival  List  process  queries  the  MSN  data  store  for  the  vessel 
arrivals  for  a  particular  port.  The  process  then  rank  orders  the  list  and 
presents  it  to  the  Supervisor  for  his  action. 

3.  The  Pick  Vessels  to  Board  process  takes  the  input  from  the  Supervisor  and 
updates  the  vessels  selected  for  boarding  and  stores  the  updated  information  in 
the  MSN  data  store. 

4.  The  Download  Vessel  Info  process  queries  the  MSN  data  store  for  a  particular 
vessel  and  boarding  for  the  port  call  which  is  provided  by  the  Boarding 
Officer.  Then  the  resulting  data  is  placed  into  the  portable  data  store  by  the 
process. 

5.  The  Update  Vessel  Data  process  takes  updated  vessel  data  and  the  results  of 
the  boarding  from  the  Boarding  Officer  and  posts  the  information  to  the 
portable  data  store. 

6.  The  Sync  Data  from  Portable  Database  process,  with  vessel  information 
provided  by  the  Boarding  Officer,  queries  the  portable  data  store  for  the 
updated  vessel  and  vessel  boarding  information  and  then  updates  the 
appropriate  records  in  the  MSN  data  store. 
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7.  The  Review  Vessel  Boarding  process  queries  the  MSN  data  store  for  the 
vessel  boarding  cases  that  are  outstanding  and  presents  a  list  to  the  Supervisor. 
Based  on  the  input  from  the  Supervisor,  the  process  then  provides  a  single 
boarding  case  and  vessel  information  package  for  the  Supervisor  to  review. 

8.  The  Update  Reviewed  Boarding  process,  takes  the  results  of  the  review  (any 
updates  to  the  case  and  if  validated  or  not)  from  the  Supervisor  and  then 
updates  the  MSN  data  store. 

9.  The  Enter  Vessel  Departures  process  provides  a  list  of  vessels  still  in  port, 
which  the  Petty  Officer  can  then  update  for  those  vessels  that  have  departed 
the  port.  The  process  then  updates  those  records  in  the  MSN  data  store. 

The  DFD  and  its  description  provide  the  design  information  needed  to  develop  the 
software  functionality  for  the  prototype.  This  coupled  with  the  database  schema  provides 
adequate  design  information  to  begin  the  construction  of  the  software  functionality 
portion  of  RePortS.  The  final  parts  of  the  design  process  are  to  identify  the  hardware  and 
user  interface  portions  of  the  prototype. 

4.  Physical  Design 

The  hardware  for  RePortS  consists  of  a  server  computer  running  Microsoft 
Windows  NT  Workstation  4.0  with  Microsoft  Internet  Information  Server  (IIS)  4.0 
installed  to  provide  the  Hypertext  Transfer  Protocol  (HTTP)  service  and  active  server 
page  (ASP)  rendering.  Since  MSN  is  designed  to  work  over  the  CGWEB,  the  client 
machine  is  connected  to  the  server  by  a  network  using  lOBase-T  Ethernet.  The  client 
machine,  running  Microsoft  Windows  95  OSR2,  uses  Microsoft  Internet  Explorer  5.01  to 
access  the  web  pages  from  the  server.  Additionally,  the  client  machine  is  a  portable 
computer,  with  Microsoft  Access  97  installed  to  provide  the  portable  database  application 
for  use  on  board  a  vessel. 

Since  the  majority  of  the  application  will  consist  of  web  pages,  an  explanation  of 
the  underlying  technology  of  IIS  and  active  server  pages  is  in  order.  IIS  is  “a  network 
file  and  application  server  for  the  Microsoft  Windows  NT  Server  4.0  operating  system.” 
(Microsoft  Press  1998,  p.  2)  IIS  provides  many  standard  Internet  services;  however,  the 
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one  of  major  importance  here  is  the  World  Wide  Web  (WWW)  service.  The  WWW 
service  supports  HTTP  1.1,  which  allows  the  publishing  of  content  to  the  Internet.  IIS 
has  features  that  allow  the  creation  and  deployment  of  Web-based  applications. 
Microsoft  calls  these  features  web  server  extensions;  the  two  that  are  used  in  RePortS  are 
ASP  and  Open  Database  Connectivity  (ODBC),  which  provide  interactive  and  dynamic 
access  to  the  database  on  the  server.  ASP  provides  the  ability  to  embed  scripts  in  a  web 
page,  which  are  executed  on  the  server  before  the  web  page  is  served  to  the  client.  ASP 
supports  the  use  of  scripting  languages  such  as  VBScript,  JScript,  and  Perl.  VBScript  is 
used  for  the  scripting  language  in  RePortS,  largely  because  of  the  convenience  of 
familiarity  and  because  it  is  easy  to  learn.  ODBC  allows  the  scripts  on  the  web  page  to 
coimect  to  the  database  on  the  server  and  allows  the  use  of  Structured  Query  Language 
(SQL)  to  extract  data  from  and  vmte  data  to  the  database.  The  combination  of  these  two 
features  forms  the  primary  software  technology  used  in  implementing  RePortS.  The 
other  technology  utilized  for  the  portable  database  application  on  the  vessel  consists  of  an 
application  built  in  Microsoft  Access  97.  The  database  on  the  portable  will  mirror  the 
database  on  the  server,  but  will  only  contain  the  information  needed  to  complete  the 
boarding  documentation  and  vessel  information  updates. 

The  final  activity  in  the  design  process  is  the  user  interface.  For  the  majority  of 
the  application,  the  web  browser  is  the  primary  interface.  The  web  pages  all  have  the 
same  graphical  look  to  make  them  a  coherent  application.  They  employ  lists,  forms,  text 
boxes,  check  boxes,  combo  boxes  and  hyperlinks  to  provide  the  interaction  with  the  user. 
The  interface  for  the  portable  database  is  in  the  form  of  an  application  built  in  Microsoft 
Access  97.  This  interface  consists  of  a  graphical  menu  system  and  forms  for  completing 
the  updating  of  the  vessel  and  boarding  data.  Screen  shots  of  the  various  pages  and  forms 
are  presented  later  in  the  roll  out  phase  of  the  design  methodology. 

B.  PROTOTYPE  CONSTRUCTION 

The  next  step  in  the  RAD  development  methodology  is  construction. 
Construction  takes  the  requirement  and  design  information  and  generates  a  software 
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solution.  The  construction  of  RePortS  has  three  distinct  activities;  database  creation,  web 
application  development,  and  portable  database  application  interface. 

1.  Database  Creation 

The  first  activity,  database  creation,  takes  the  database  schema  created  in  Section 
A.  and  creates  the  tables  and  relations  in  the  database.  For  RePortS,  the  database  is 
created  in  Microsoft  Access  97.  The  procedure  for  completing  this  is  as  follows.  Tables 
are  created  and  data  members  are  entered  in  the  design  window  for  the  table;  extensive 
use  of  drop  down  boxes  and  other  visual  aids  make  this  process  proceed  quickly. 
Primary  keys  are  identified  for  the  tables  and  are  noted  with  a  key  icon  in  the  design 
window  of  the  table.  Once  the  tables  are  created,  the  relations  have  to  be  created  in  the 
relationship  window.  This  is  accomplished  by  using  a  drag  and  drop  method  of  dragging 
the  key  field  of  one  table  to  the  related  field  of  another  and  then  filling  in  the  form  that 
pops  up  when  the  mouse  button  is  let  up.  Upon  completion  of  the  table  and  relationship 
creation  process,  the  database  is  ready  to  use.  The  tables  are  filled  in  with  some  fictitious 
but  realistic  data  to  allow  demonstration  of  RePortS  at  roll  out. 

2.  Web  Application  Development 

The  second  activity,  web  application  development,  is  a  more  complicated 
undertaking.  This  is  due  to  the  amount  of  code  and  application  logic  that  needs  to  be 
created  for  RePortS  to  work.  As  mentioned  in  Section  A,  the  technology  used  in  creating 
the  web  application  is  ASP  with  VBScript  and  an  ODBC  connection  to  the  database. 
There  are  three  basic  building  blocks  used  in  the  creation  of  the  web  pages  for  the  web 
application: 

1 .  the  connection  to  the  database; 

2.  an  SQL  query  that  is  passed  to  the  database  via  the  connection; 

3.  the  manipulation  of  the  data. 

To  facilitate  the  discussion  of  the  three  building  blocks,  a  portion  of  a  web  page 
developed  for  RePortS  is  provided  in  Table  5-3.  Line  numbers  have  been  added  to  assist 
in  identifying  the  parts  of  the  code. 


91 


1<% 

2  SQLAGENT=”SELECT  PartylD,  PartyName  FROM  INTPARTY  WHERE  PartyRole  =  *agenf” 

3  set  coimagent  =  server.createobject("ADODB.Comiection”) 

4  connagent.open  ”test2" 

5  set  agents=coimagent.execute(SQLAGENT) 

6%> 

7  <select  name=”AgentID”> 

8  <%  do  while  not  agents.eof  %> 

9  <Option  value  =  "<%==  agents(O)  %>">  <%=  agents(l)  %x/Option> 

10  <%agents.movenext 

11  loop%> 

12  </select> 

13  <%  connagent . close  %> 

Table  5-3.  Web  Page  Code 

Before  covering  the  three  basic  building  blocks,  the  structure  of  the  code  is 
described  for  those  unfamiliar  with  ASP.  ASP  code  is  usually  contained  in  Hypertext 
Mark  up  Language  (HTML)  documents.  HTML  uses  tags  to  provide  instructions  to  web 
browsers  on  how  to  display  a  document.  ASP  uses  specific  tags  to  indicate  to  the  web 
server  that  the  items  contained  within  the  tags  are  script  to  be  processed  before  delivering 
the  page  to  the  web  browser.  The  tags  used  for  ASP  are  identified  as  ‘<%  %>’  with  the 
code  to  be  run  inside  of  the  tags.  Once  the  server  has  processed  the  code,  the  result  is  a 
document  that  has  been  dynamically  built  and  delivered  to  the  client.  The  code  in  Table 
5-3  is  used  in  RePortS  to  create  a  drop  down  list  box  populated  with  items  for  inclusion 
on  another  web  page.  With  this  background  covered,  the  next  step  is  to  describe  the  three 
basic  building  blocks  used  in  the  creation  of  RePortS. 
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a.  Connection  to  the  Database 


The  first  of  the  basic  building  blocks  of  the  web  application  development 
activity  is  the  connection  to  the  database.  The  connection  to  the  database  is 
accomplished  using  ActiveX  Data  Objects  (ADO),  a  technology  developed  by  Microsoft 
to  access  databases  through  ODBC.  In  order  to  make  the  connection  to  the  database  on 
the  server,  the  database  must  be  registered  with  a  system  data  source  name  (DSN)  in  the 
ODBC  applet  that  is  found  in  the  control  panel  of  the  server  computer.  A  connection  can 
then  be  established  via  ADO  in  code  in  the  web  page.  Line  number  three  in  Table  5-3 
shows  the  creation  of  the  data  object  on  the  server.  Creating  the  object  is  done  by  calling 
the  ‘createobject’  method  of  the  server  object  with  the  parameter  of 
‘ADODB.Connection’,  and  then  assigning  the  result  into  a  variable  called  ‘connagent’. 
The  next  step  is  to  open  the  connection,  as  shown  in  line  four,  and  is  achieved  by  calling 
the  ‘open’  method  of  the  just  created  connection  object  and  passing  the  DSN  of  the 
database  for  which  the  connection  is  desired.  The  connection  to  the  database  is  then 
ready  to  be  used  to  communicate  with  the  database.  After  the  connection  has  been  used 
for  the  last  time,  it  is  closed,  as  shown  in  line  13.  Calling  the  ‘close’  method  of  the 
connection  object  closes  the  connection. 

b.  SQL  Query 

The  second  basic  building  block  of  the  web  application  development 
activity  is  the  SQL  query.  The  retrieval,  updating  and  deleting  of  data  in  the  database  is 
accomplished  using  SQL  queries.  The  query  is  put  into  a  variable  and  then  passed  to  the 
database  using  the  connection  object.  Li  the  example  in  Table  5-3,  the  query  is  sent  to 
the  database  in  line  number  five  by  calling  the  ‘execute’  method  of  the  connection  object 
with  the  query  variable  as  the  parameter.  The  results  are  returned  as  a  record  set  and 
saved  for  further  processing  in  a  variable.  The  query  in  this  example  is  a  simple  query, 
which  does  not  contain  any  other  variables.  Many  of  the  queries  in  the  application  use 
variables  that  are  passed  from  page  to  page  and  query  multiple  tables  in  the  database. 
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c.  Manipulation  of  Data 

The  third  basic  building  block  of  the  web  application  development  activity 
is  the  manipulation  of  the  data.  This  is  the  stage  where  the  data  provided  by  the  query 
through  the  connection  to  the  database  is  used,  modified  or  updated.  In  the  example  in 
Table  5-3,  lines  seven  through  twelve  show  simple  manipulation  of  the  record  set 
provided  by  the  query.  The  record  set  also  has  methods  that  allow  the  movement  of  a 
cursor  to  the  different  rows  in  the  record  set.  There  are  also  methods  used  to  determine 
the  placement  of  the  cursor  (e.g.,  beginning  of  file  [bof]  or  end  of  file  [eof]).  In  the 
example,  the  ‘movenext’  method  is  called  to  move  the  cursor  to  the  next  record  in  the 
record  set.  The  columns  of  the  record  set  are  accessed  by  using  subscripts  with  the  first 
column  being  zero.  In  the  example,  the  code  creates  a  drop  down  list  box  filled  with  data 
for  use  in  another  page.  To  understand  how  this  is  done  each  line  will  be  explained: 

1 .  Line  7  is  an  HTML  tag,  which  assigns  a  unique  identifier  to  the  drop  down 
list  box;  this  is  for  identifying  the  selection  of  the  drop  down  list  box  when 
the  information  is  sent  to  the  server. 

2.  Line  8  is  a  do  loop  which  tests  to  see  if  the  end  of  the  record  set  has  been 
reached,  and  if  not,  the  items  after  the  statement  are  executed. 

3.  Line  9  is  the  assignment  of  the  data  to  the  list  of  the  drop  down  list  box.  The 
first  column  is  assigned  to  the  value  to  be  passed  and  the  second  column  is 
the  information  the  user  will  see  when  the  list  box  is  opened. 

4.  Line  10  moves  the  cursor  to  the  next  record 

5.  Line  1 1  causes  the  loop  to  move  execution  back  to  line  eight. 

Once  the  end  of  the  file  is  reached,  the  drop  down  list  box  has  been  populated  with  data 
and  is  ready  for  use.  Other  more  complicated  manipulations  of  data  are  used  in  RePortS, 
however  the  concept  of  the  manipulation  is  the  same. 

d.  Summary  of  Basic  Building  Blocks 

This  subsection  has  shown  the  basic  building  blocks  used  in  the  web 
application  development.  Every  ASP  page  used  in  the  application  uses  some  form  of 
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each  of  the  blocks  to  carry  out  the  functionality  of  the  page.  Although  some 
implementations  might  be  more  complex  than  the  example  shown  in  Table  5-3,  the  basic 
ideas  behind  them  are  the  same. 

3.  Portable  Database  Application  Interface 

The  third  activity  is  the  portable  database  application  interface.  The  portable 
database  is  a  copy  of  the  server  database  without  all  of  the  data  the  server  database 
contains.  The  interface  for  this  database  is  built  in  the  Access  97  application  itself 
Using  the  wizards  to  build  the  data  entry  forms,  queries,  reports  and  menu  navigation 
system  is  a  point  and  click  process.  After  the  wizard  has  created  the  required  objects, 
they  are  cleaned  up  and  graphics  are  added  to  create  a  coherent  application. 

C.  ROLLOUT 

The  final  phase  of  the  RAD  development  cycle  is  the  roll  out  of  the  product.  If 
the  RAD  development  cycle  were  to  be  used  for  an  actual  production  system,  the  design 
and  constmction  phases  would  cycle  a  few  times  so  the  users  of  the  system  could  provide 
feedback  to  the  designers.  In  the  case  of  RePortS,  several  iterations  have  occurred  while 
designing  and  constructing  the  prototype. 

To  provide  a  view  of  the  fimctionality  of  RePortS,  the  flow  of  one  vessel  through 
the  system  is  depicted  and  explained  using  screen  shots  of  the  different  web  pages  of  the 
application.  Note  that  no  security  measures  such  as  authenticated  log  in  or  restricting 
user  access  to  parts  of  the  system  have  been  implemented  in  RePortS.  Implementing 
security  aspects  depends  heavily  upon  the  technology  used  for  implementation  such  as 
the  database  system,  web  server  and  server  operating  system.  Since  the  main  purpose  of 
the  prototype  is  to  show  feasibility  of  the  redesigned  process,  no  security  measures  were 
included.  Two  possible  methods  of  providing  security  for  the  full,  operational  system 
will  be  mentioned  briefly.  The  first  is  using  the  security  features  of  IIS  and  Microsoft 
Windows  NT  Server.  When  using  these  features,  access  to  certain  parts  of  the  web  site  is 
restricted  to  only  those  who  supply  a  valid  Windows  NT  user  name  and  password. 
Additionally,  the  user  name  and  password  are  encrypted  for  transmission.  The  second 
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method  is  to  use  the  underlying  database  system  to  provide  user  names  and  passwords 
and  to  use  Secure  Sockets  Layer  (SSL)  to  provide  user  name  and  password  encryption. 
Since  the  CGWEB  is  an  intranet  and  is  only  accessible  to  those  behind  the  firewall,  the 
use  of  Windows  NT  user  names  and  passwords  could  be  used  for  those  portions  of  the 
web  site  that  are  for  Coast  Guard  use  only.  For  the  vessel  agents,  unique  user  names  and 
passwords  could  be  supplied  and  SSL  could  be  used  for  encryption. 

The  home  page  of  the  system  is  a  page  that  welcomes  the  user  and  presents  a 
number  of  options.  To  begin  the  tour  of  the  system,  the  hyperlink  on  the  home  page 
(Figure  5-4)  for  entering  a  vessel  arrival  is  clicked.  This  sends  the  user  to  another  page, 
shown  in  Figure  5-5,  which  allows  the  entry  of  a  vessel  name. 


^  Prototype  Home  Page  >  Microsoft  Internet  Explorer  provided  by  ZDNet 


HBE3 


as.  COASTGUARD 


Welcome  to  the  PSC  prototype  web  site! 


Agents 

Click  here  to  give  of  vessel 


Coast  Guard 

Click  here  to  \ne\v  vessel  airival  list. 

Click  here  to  vessels  selected  for  boardirxg- 
Click  here  to  view  vessel  boardings  to  review. 
Click  here  to  enter  vessel  departures. 


http://192.168,0.2/ve^,entiy.htm  ;  :  i  . 


I®  li^ernet 


.. 


Figure  5-4.  Prototype  Home  Page 


When  the  submit  button  is  clicked,  the  vessel  name  is  searched  for  in  the  database 
on  the  server.  If  there  is  a  match,  a  page  is  presented  to  the  user  with  all  matches  and 
additional  identifying  information  on  the  matching  vessels  (Figure  5-6). 
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Figure  5-5.  Vessel  Name  Entry  Page 


^  Pick  the  Vessel  -  Microsoft  Internet  Explorer  provided  by  ZDNet 


ZD 


hltp:  //1 92. 1 68. 0. 2 /results,  asp 


iiMiU.S.  COASTGUARD 


Click  on  the  vessel  id  you  wish  to  provide  the  arrival  notice  for. 


9012j^  Miramar  Liberia 
5643^  Miramar  Greece 

E.eturn  to  Horne  Pa£re 


http://1 9Z1 68.0.Zi'enter_arrival.asp?vhi=1  ScvsWame=Miranartdmo=901 234 


Figure  5-6.  Selection  of  Vessel 


Internet 
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Now  the  user  can  select  the  appropriate  vessel  by  clicking  on  the  IMO  number  of 
the  vessel.  This  brings  up  a  page  that  allows  the  user  to  enter  the  information  for  the 
arrival  of  the  vessel  using  text  boxes  and  drop  down  list  boxes.  This  is  shown  in  Figure 
5-7.  When  the  user  clicks  on  the  submit  button,  the  information  is  sent  to  the  server.  The 
server  then  updates  the  data  in  the  database,  gathers  information  for  the  grading  of  the 
vessel,  grades  the  vessel,  and  updates  the  priority  of  the  vessel.  A  confirmation  is 
returned  to  the  user  of  the  acceptance  of  the  arrival  notice  along  with  a  message  on  the 
priority  and  likelihood  of  a  PSC  boarding  (Figure  5-8). 


'3  Enter  Vessel  Arrival  -  Microsoft  Internet  Explorer  provided  by  ZD  Net 


ir. 


:  COASTGUARD 


Enter  the  arrival  information  for  the  vessel  Miramar  IMO  number  901234. 


Arrival  Date:  5/21/00 


Agent  Name:  |Southco  H 
Arrival  Port 


MSO  LA-LB 


I  Sc^it  I  Reiet  I 


1  PCetuiii  to  Horne  Page 

®  Done 

j  Internet  ^ 

Figure  5-7.  Vessel  Arrival  Entry  Page 
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Internet 


Figure  5-8.  Arrival  Acceptance  and  Priority  Read  Out 


With  the  vessel  arrival  entered  into  the  system,  the  PSC  supervisor  can  now  click 
on  the  link  for  viewing  the  vessel  arrivals  in  the  port.  (See  Figure  5-4)  This  link  takes  the 
user  to  a  page  where  he  can  enter  the  port  for  the  list  of  arrivals  he  desires.  (See  Figure  5- 

9) 


-3  GG  Enter  Port  -  Microsoft  internet  Explorer  provided  by  ZDNet 


Enter  Your  Port  Name:  MSO  LA-LB 


Submit 

— tr 


pLeten  to  Home  Page 


Done 


Ir^ernet 


Figure  5-9.  Selection  of  Port 


After  providing  the  information,  a  list  of  all  the  vessel  arrivals  to  the  port  is 
presented  with  those  scoring  the  highest  number  of  points  in  the  grading  process  at  the 
top  of  the  list.  This  provides  the  decision  support  for  selecting  the  vessels  to  board.  The 
list  has  check  boxes  next  to  each  vessel  for  the  user  to  select  which  vessels  are  targeted 
for  boarding  that  day.  (See  Figure  5-10)  When  the  user  has  checked  the  vessels  he  wants 
boarded,  he  clicks  on  the  submit  button,  and  the  selected  vessel  boarding  records  are 
updated.  The  user  is  then  presented  with  an  acknowledgement  of  his  actions. 
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List  of  Vessel  Arrivals  -  Microsoft  Internet  Explorer  provided  by  ZDNet 


HOB 


ZD 


hltp:  //1 92. 1 B8. 0. 2/cgLport_arrivals.  asp 


STGUARi 


The  vessels  listed  below  are  vessels  which  have  not  been  targeted  for  a  boarding. 
The  Hst  is  presented  in  priority  order  with  those  scoring  the  most  points  in 
a  given  priority  class  listed  in  order  of  highest  number  of  points  to  lowest 


Select  the  vessels  you  want  to  target  for  a  boarding  and  click  on  the  "submit"  button. 

List  of  Vessel  Arrivals  for  MSO  LA-LB 


Chk  jVessel  Name  YEN 

Hag 

Arrival  Date 

Agent  Name 

ISSSSU 

1 17  i  Miramar  1 1  ILiberia 

5/21/00 

Southco 

2  ; 

P  Exxon  Valdez  \3 

Marshall  Islands 

6/1/00 

Inchcape 

4 

Submit  j  Reset 

"T” 


Ps.etJim  to  Horne  Paere 


Done 


I  ,  ! 

I  i 


inferret 


Figure  5-10.  List  of  Vessel  Arrivals 


The  boarding  officer  assigned  to  the  boarding  selects  the  link  to  view  vessels 
selected  for  boarding.  This  generates  a  list  of  vessels  selected  for  boarding  in  the  port. 
The  boarding  officer  selects  the  vessel(s)  he  has  been  assigned  by  checking  the  check  box 
and  clicking  the  submit  button.  (See  Figure  5-11)  The  boarding  and  vessel  data  needed 
for  the  boarding  are  downloaded  to  the  portable  database  and  the  boarding  officer  is 
ready  to  perform  the  boarding. 


101 


3  Vessels  Selected  For  Boarding  -  Microsoft  Internet  Explorer  provided  by  ZDWet 


^  http7/l  92.1 68.Q.2/cgLview_boardings.a$p 


STGUARD 


The  vessels  listed  below  are  vessels  which  have  been  targeted  for  a  boarding. 
The  list  is  presented  in  priority  order  with  ihose  scoring  the  most  points  in 
a  given  priori^  class  listed  in  order  of  highest  number  of  points  to  lowest, 


To  download  the  vessel  case  information  for  the  boarding,  check  the  checkbox  next 
to  the  vessels)  desired.  When  you  have  made  your  selections  click  on  the  "submit"  button. 

Vessds  Sdected  for  Boarding  at  MSO  LA-LB 


Chk  Vessel  Name 

VIN; 

Flag 

Arrival  Date 

Agent  Name  Priontjr 

f|7|  iMiramar 

1  ; 

Liberia! 

5/21/00 

Southco  ii2 

1  n  ;|Miramar 

4 

Greece; 

5/14/00 

Sovitiico  ;i2 

F  {Miramar 

4 

Greece: 

5/16/00 

Soiithco  :i4 

Sulpgiit  I  Reset 


ReUim  to  Home  Page 


®  Dor» : 


Intent" 


A 


Figure  5-11.  Vessels  Selected  for  Boarding 


Figure  5-12  shows  the  menu  for  the  portable  application.  The  options  shown  on 
the  figure  allow  the  user  to  access  the  different  forms  of  the  application.  Figure  5-13  is 
a  screen  shot  of  a  boarding  update  form  that  the  boarding  officer  would  use  while  on 
board  the  vessel.  The  next  screen  shot,  Figure  5-14,  shows  the  certificate  update  page  for 
use  on  the  vessel.  When  the  boarding  is  complete,  a  vessel  boarding  letter  is  generated 
from  the  data  entered  during  the  boarding  (See  Figure  5-15),  printed  out  and  left  with  the 
Master  of  the  Vessel.  When  the  boarding  is  completed,  the  data  in  the  portable  database 
is  uploaded  to  the  server,  thus  updating  the  vessel  and  boarding  data. 
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Upd^e  Vessel/Boarding  Information 
Create  On  Board  Reports 
Eat  Ws  af^fcation 


Figure  5-12.  Portable  Application  Menu 


^  BOARDING 


mm 


Vessel  Boarding  Data  Entry  Form 


11 


Case  Ninabei:  [ 

Boardmg  Tj^pe: 
AnivalDate: 

Tcrtai  Points: 

.  ........ 

Priority:  I  2 

Boarding  Date:  |5y20/2000 
Boiling  Place:  jBerth  F21 
In  Process:  W~ 
jvessel  Detairwd?:  C 
Op  Control?: 

Date  Ctose±  |  ! 


Closed?:  C 


Boardmg  Time:  [" 
Veu  r 


13 


Port  ID:  jMSO  LA-LB 

Agent  ID: 

Detais: 


Conducted  Annual  exam,  no  problems 
noted-l 


Close  Fonn 


Recordj  1  ^  I  f 


9  14 


Figure  5-13.  Vessel  Boarding  Entry  Form 
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M  Certificate  Entry 


B1I3E3 


Vessel  Certificate  Update/Entry  Form 


Vessel  Name:  [Miramar 


"  IMONuniiHM:[  901234  Rag  Slate:  (LI  _  ^  ^ 


Cei 

rtm^es 

Cert  Type 

Is^eDate 

Endoi^  Date 

Expire  Date  '  Iswed  At  ' '  H 

SEC 

ABS 

4/7/1997; 

4/3/2000; 

4/7/2001;  HoustonJK _ 1 

S| 

T 

Load  Line 

see 

lOPP" 

1 

;abs 

ABS 

abs  '  " 

5/6/1998 
;  5/21/2000 
. 6/8/1999 

5/14/1999 

5/B/20g0;Houston/‘P<  i 

5/21/2005;  Singapore  a 

6^/2004;  Kuala  Lampor  ^ 

Record:  h1  <  If 

Record:  I  ^1f 


5  ri  M  l»*l  of: S  ' 


Figure  5-14.  Vessel  Certificate  Update  Form 


USCG  Port  State  Cimlrol 
Vessel  Exammation  Letter 

Master,  MV  Miramar  IMONmtiiber  564322, 

On  5/20/2000  50  ur  vessel  vras  examined  by  oSlcers  from  MSO  lA-LB 
at  Berth  F21  . 

The  results  of  the  exammation  are  described  below': 

No  Discrepacies  found. 

Please  keep  a  copy  of  this  letter  onboard  ard  provide  it  to  the  next  U.S.  Coast  Guard 
personnel  whD  board  5?our  vessel.  A  record  of  this  boarding  has  been  made  into  the  U.S. 
Coast  Guard  h/briie  Safe  ty  Ne  twork  ard  is  noted  as  case  number;  9 

Boarding  05ice  r  Tim  Kurc  kle  BM3  USCG 


Figure  5-15.  Vessel  Examination  Letter 

At  this  stage,  the  supervisor  can  access  the  list  of  vessels  that  have  been  boarded 
and  know  that  the  information  has  been  synchronized  with  the  server  database.  This 
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provides  a  list  of  vessels  from  which  the  supervisor  can  select  to  review  the  boarding  case 
and  vessel  information  updates  (See  Figure  5-16).  Once  the  supervisor  has  reviewed  and 
approved  the  case,  the  validate  box  is  checked,  and  the  boarding  record  is  updated  with 
the  information  (See  Figure  5-17).  The  supervisor  gets  an  acknowledgement  of  the 
validation  and  can  view  additional  vessel  boarding  cases. 


'^Vessel  Cases  to  Review  -  Microsoft  Internet  Explorer  provided  byZDNet 


To  review  one  of  flie  vessel  boardings  from  the  list  below,  cEck  on  the  case 
number  to  pull  up  the  case  information. 


Vessel  Boardings  at  MSO  LA-LB 


Case  Number  IBoarding  Type  Vessel  Name  jVIN  |  Hag 
ANN  [Miramar  4  JGreece 


:  Miramar 


:  Hocon  Valdez  3  jMarshall  Islands  15/20/00 


J  Retiin'i  to  Homepage 

f*tp://192168.0.2/cg_vsLreview_pg.asp?Ca^urn^  ’ .  , ‘  ;; 


Figure  5-16.  List  of  Vessels  to  Review 


15/20/00 


15/20/00 


Internet 


The  final  activity  in  the  PSC  process  is  the  logging  of  vessels  that  have  departed 
the  port  and  were  not  boarded.  Figure  5-18  shows  this  list.  The  list  allows  the  user  to 
select  the  vessels  that  have  departed  the  port  and  to  enter  the  date  of  departure.  When  the 
submit  button  is  clicked,  the  selected  records  are  updated  in  the  database  along  with  an 
acknowledgement  of  the  updates. 
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,ase  Review  Page  -  Microsort 


xplorer  providea  oy 


Boarding  Case  Information 

Items  in  blue  cannot  he  edited. 


jviN 

^^^essel  Namei 

pDVIO  Number 

. . . . . 

Flag  State 

:4 

jMiramar 

|564322 

Greece  | 

Case  Number 


Boarding  Type  Arrival  Date  Priority  iBoarding  Date 


Boarding  Location 


15/21/00 


[5/20/00 


> — 

Vessel  Detained? 

Op  Control  Imposed? 

Time  on  Boarding 

r 

r 

0  ! 
— - ^ - 

Boarding  Details 


n  Check  here  to  validate  case. 
Submit 


Internet 


Figure  5-17.  Vessel  Boarding  Review  Page 


d 


►6 


^Vessels  in  Port  *  Microsoft  Internet  Explorer  provided  by  ZD  Net 


//m/U.S.  COAST  Gl/A/fD 


This  is  the  list  of  vessels  in  the  port  that  were  not  boarded.  Select  the  vessels  which  have 
departed  by  checking  the  check  box  and  enter  the  departure  date  in  the  departure  date  field. 


When  finished,  click  on  the  “submit"  button. 
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Figure  5-18.  List  of  Vessels  Not  Boarded 


D.  SUMMARY 


This  Chapter  has  presented  the  development  of  a  prototype  to  implement  the 
redesigned  process  discussed  in  Chapter  IV.  The  RAD  methodology  was  used  in  the 
development  process.  Requirements  and  design  were  presented,  data  and  process  models 
were  created,  and  the  construction  of  the  prototype  was  explained.  Finally,  RePortS  was 
demonstrated  by  providing  a  use  case  walk  through  of  the  system  using  screen  shots  to 
explain  the  process  flow  for  a  particular  vessel.  The  prototype  has  demonstrated  that  the 
implementation  of  the  redesigned  PSC  process  is  feasible,  and  shows  how  the  redesigned 
process  would  look  in  implementation  form. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  main  purpose  of  this  thesis  is  to  analyze  and  perform  a  business  process 
redesign  of  the  U.  S.  Coast  Guard  Port  State  Control  process.  The  focus  is  to  provide 
innovative  solutions  that  dramatically  improve  the  cycle  time  and  data  accuracy  of  the 
process. 

A.  CONCLUSIONS 

The  current  process  consists  of  sixteen  activities  ranging  from  the  vessel  agent 
calling  in  a  vessel  arrival  to  the  final  step  of  logging  the  departure  of  the  vessel.  The 
goals  of  the  process  are  timeliness  and  accuracy  in  the  identification  of  vessels  requiring 
boarding,  in  the  gathering  of  data  on  the  current  state  of  a  vessel  being  boarded,  and  in 
the  documentation  of  vessel  boardings.  Process  cycle  time  and  data  accuracy  are  the 
critical  performance  measures  for  the  process. 

Of  the  three  major  approaches  to  BPR,  process  reengineering,  process  redesign 
and  continuous  process  improvement,  process  redesign  was  selected  as  the  most  suitable 
methodology.  The  steps  to  accomplish  the  redesign  are  specified  as: 

1 .  Process  Identification 

2.  Process  Modeling 

3.  Configuration  Measurement 

4.  Pathology  Diagnosis 

5.  Matching  of  Transformations 

6.  Generation  of  Redesigns 

7.  Testing  of  Alternatives 

8.  Selection 

9.  Implementation 

The  overall  PSC  process  was  decomposed  into  two  separate  processes,  the 
targeting  process  and  the  vessel  boarding  process.  Each  of  the  processes  was  analyzed  by 
the  KOPeR  system  to  identify  potential  pathologies  with  respect  to  the  process  measures 
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of  size,  length,  handoffs,  feedback  loops,  IT  support,  IT  communication  and  IT 
automation.  The  pathologies  identified  for  both  processes  were: 

1 .  Sequential  Process 

2.  Process  Friction 

3.  Inadequate  IT  Support 

4.  Inadequate  IT  Communications 

5.  Inadequate  IT  Automation 

The  recommendations  for  the  targeting  process  redesign  were  to: 

1.  Delinearize  by  automating  the  call  in  and  grading  activities,  which  would 
allow  them  to  operate  in  parallel. 

2.  Create  a  case  manager  by  automating  the  call  in  and  grading  process,  and 
provide  an  automated  decision  support  mechanism. 

3.  Provide  additional  IT  support  by  leveraging  the  CGSWni  and  MSN  contracts. 

4.  Provide  IT  communication  by  using  MSN  to  keep  records  and  provide  the 
lists  traditionally  kept  on  paper. 

5.  Provide  IT  automation  by  having  a  computer  perform  the  grading  and  logging 
activities  of  the  process. 

The  recommendations  for  the  vessel  boarding  process  were  to: 

1 .  Provide  additional  IT  support  by  using  the  CGSWIII  and  MSN  to  support  the 
process  and  use  a  portable  database  application  to  support  operations  on  board 
a  vessel. 

2.  Provide  IT  communication  by  using  MSN  to  keep  records  and  use  a  portable 
database  application  with  a  synchronizing  method  to  pass  boarding 
information. 

3.  Provide  IT  automation  by  keeping  the  official  record  of  vessel  boardings 
electronically. 

Simulation  models  were  constructed  of  the  current  and  proposed  redesigned 
processes  with  simulation  runs  conducted  to  gather  data  for  the  critical  performance 
measures.  Each  redesigned  process  incorporated  simulation  runs  with  three  different 
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scenarios;  most  likely,  optimistic  and  pessimistic.  This  provided  a  balanced  look  at  the 
possible  gains  provided  by  the  redesign  effort.  The  redesigned  processes  were  then 
compared  against  the  current  processes  to  identify  areas  of  improvement  in  the  critical 
performance  measures.  The  results  of  the  simulation  models  showed  a  potential  savings 
of  between  5821.75  and  2308.6  hours  per  year  for  the  targeting  process  and  a  potential 
savings  of  between  4777.9  and  829.8  hours  per  year  for  the  vessel  boarding  process.  The 
simulation  results  provide  evidence  of  convincing  time  savings  resulting  from  the 
redesign. 

A  prototype  of  the  system  required  to  implement  the  redesigned  PSC  process  was 
developed.  Tools  were  identified  and  expectations  set  for  the  prototype.  The  RAD 
method  of  systems  development  was  selected  as  the  development  methodology  and 
discussed.  Requirements  were  identified  from  Chapter  IV  and  documented  using  a  SOM, 
database  schema,  and  DFD.  The  prototype  was  constructed  using  a  database,  ASP, 
VBScript,  and  a  portable  Microsoft  Access  database  application.  The  prototype 
application  was  demonstrated  via  the  execution  of  a  use  case  study  to  show  the  feasibility 
of  implementing  a  system  redesign  as  proposed. 

This  thesis  has  conducted  an  analysis  and  redesign  of  the  PSC  process  using  BPR 
methods,  discrete  event  simulation  and  a  prototype  implementation  of  the  redesign.  The 
simulation  model  indicates  that  implementing  the  modifications  of  the  process  design 
would  result  in  significant  manpower  savings,  ranging  from  2  to  4  person  years.  The 
prototype  establishes  convincing  proof  of  concept  indicating  the  redesign  is  eminently 
feasible. 

B.  RECOMMENDATIONS 

Based  upon  the  results  above,  the  following  recommendations  are  made: 

1.  The  Coast  Guard  should  implement  the  proposed  redesign  presented  in  this 
thesis.  The  course  of  implementation  should  begin  by  providing  the  targeting 
process  functionality  with  MSN.  The  vessel  boarding  process  should  be 
initially  started  as  a  pilot  program  in  several  of  the  larger  ports  to  validate  the 
simulation  results  and  identify  costs  regarding  implementation. 
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2.  During  the  course  of  this  research,  the  Coast  Guard  has  independently 
implemented  some  of  the  ideas  presented  in  this  thesis  with  the  MSN,  for 
example,  the  automated  grading  and  targeting  of  vessels.  With  a  team  of 
developers  already  working  on  MSN,  additional  features  identified  in  this 
thesis,  such  as  the  portable  database  application  and  vessel  agent  provided 
web  based  vessel  arrival  information,  should  be  explored  for  subsequent 
implementation  in  MSN. 

3.  The  premise  of  this  thesis  can  be  extended  to  other  marine  safety  processes 
that  will  be  customers  of  the  MSN,  such  as  the  casualty  investigation  process, 
the  domestic  vessel  boarding  process,  and  the  oil  spill  investigation  process. 
These  extensions  could  be  the  topic  for  a  “follow  on”  thesis,  or  the  Coast 
Guard  could  use  similar  methods  to  those  implemented  in  this  thesis  to 
perform  a  BPR  on  the  processes  themselves. 

C.  FUTURE  RESEARCH 

The  following  are  areas  identified  for  future  research  considerations: 

1.  The  prototype  was  unable  to  be  field  tested  to  provide  actual  numbers  for 
comparison  against  the  simulation  model.  Another  area  of  research  is  be  the 
complete  production  of  a  prototype,  building  upon  the  work  already  done  with 
MSN  in  conjunction  with  this  thesis,  for  use  in  performing  a  field  test  of  the 
system.  This  would  provide  additional  insight  into  the  validity  of  the 
simulation  models  and  their  extensibility  to  other  processes. 

2.  Finally,  an  additional  area  for  further  research  is  the  development  of  a  more 
robust  decision  support/expert  system  in  determining  the  highest  risk  vessels 
entering  a  port.  The  PSC  program  has  been  operating  for  five  full  years  and 
there  is  a  large  amount  of  data  in  MSIS  that  could  be  put  into  a  data 
warehouse  and  analyzed  using  data  mining  techniques.  With  the  information 
gleaned  from  this  data,  specific  risk  profiles  could  be  identified  to  assist  with 
the  targeting  process. 
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APPENDIX  A.  PSC  TARGETING  MATRIX 


This  is  a  copy  of  the  Port  State  Control  Targeting  Matrix  from  the  Coast  Guard 
Marine  Safety  Manual,  Volume  II. 


OWNER 

FLAG 

CLASS 

HISTORY 

SHIP  TYPE 

5  Points 

7  Points 

Priority  1 

5  Points  Each 

1  Point 

Listed  Owner 

Listed  Flag 

>10  arrivals  with  detention 

Detention 

Oil  or  chemical 

or  Operator 

State 

ratio  more  than  4  times  the 

within  the 

Tanker 

average  OR  <10  arrivals  and 

previous  12 

involved  with  at  least  one 

months. 

1  Point 

detention  in  the  previous  3 

Gas  Carrier 

years. 

1  Point  Each 

2  Points 

Other 

Bulk  Freighter 

5  Points 

operational 

over  1 0  years  old. 

>10  arrivals  with  a  detention 

control  within 

1  Point 

ratio  between  3  &  4  times 

the  previous  12 

Passenger  Ship 

the  average. 

months 

2  Points 

Carrying  low 

3  Points 

1  Point  Each 

value 

>10  arrivals  with  a  detention 

Casualty  within 

commodities  in 

ratio  between  2  &  3  times 

the  previous  12 

bulk. 

the  average. 

months. 

1  Point 

1  Point  Each 

>10  arrivals  with  a  detention 

Violation  within 

ratio  between  the  average 

the  previous  12 

and  twice  the  average. 

months. 

0  Points 

1  Point  Each 

>10  arrivals  with  a  detention 

Not  boarded 

ratio  below  the  average  OR 

within  the 

<10  arrivals  with  no 

previous  6 

detentions  in  the  previous  3 

months. 

years. 
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APPENDIX  B.  DATA  DEFINITION 


This  appendix  contains  the  data  definition  for  the  database  schema  described  in 
Chapter  V. 


Table 

Attributes 

Type  (size) 

Key/Foreign  Key 

VESSEL 

Vin 

AutoNumber 

Key 

IMONumber 

Number 

VslName 

Text(25) 

BldDate 

Date/Time 

VslType 

Text(3) 

Length 

Number 

Breadth 

Number 

Depth 

Number 

Propulsion 

Text(15) 

SpecialNote 

Text(240) 

ClassID  FK 

Number 

FK 

FlagID  FK 

Number 

FK 

BOARDING 

CaseNum 

AutoNumber 

Key 

Type 

Text(5) 

Tpoints 

Number 

Priority 

Number 

ArrivalDate 

Date/Time 

BdngDate 

Date/Time 

BdngPlace 

Text(35) 

InProc 

Yes/No 

Detained 

Yes/No 

OpControl 

Yes/No 

DateClosed 

Date/Time 

Closed 

Yes/No 

Details 

Text(254) 

BoardingTime 

Number 

Vin  FK 

Number 

FK 

PortID_FK 

Number 

FK 

PartylD  FK 

Number 

FK 
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Table 

Attributes 

Type  (size) 

CLASS 

ClassID 

ClassCode 

ClassName 

Street 

City 

State 

Country 

Zip 

PhoneNo 

TPoints 

AutoNumber 

Text(6) 

Text(35) 

Text(20) 

Text(20) 

Text(4) 

Text(3) 

Number 

Text(15) 

Number 

Key 

INTPARTY 

PartylD 

PartyName 

PartyRole 

Street 

City 

State 

Country 

Zip 

PhoneNo 

TPoints 

AutoNumber 

Text(25) 

Text(lO) 

Text(20) 

Text(20) 

Text(4) 

Text(3) 

Number 

Text(15) 

Number 

Key 

DBF 

DefID 

CaseNum_FK 

DefType 

DefCode 

FixBy 

Problem 

DateClosed 

Closed 

Number 

Number 

Text(25) 

Text(5) 

DateATime 

Text(50) 

Date/Time 

Yes/No 

Key 

Key/FK 

FLAGSTATE 

FlagED 

FlagCode 

CoimtryName 

Street 

City 

State 

Zip 

PhoneNo 

TPoints 

AutoNumber 

Text(3) 

Text(15) 

Text(20) 

Text(20) 

Text(4) 

Number 

Text(15) 

Number 

Key 

VESSEL- 

INTPARTY 

Vin_FK 

PartylD  FK 

Number 

Number 

Key/FK 

Key/FK 
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Table 

Attributes 

Key/Foreign  Key 

CERTIFICATE 

CertType 

Text(7) 

Key 

Vin_FK 

Number 

Key/FK 

IssuedBy 

Text(15) 

IssueDate 

Date/Time 

EndorseDate 

Date/Time 

ExpireDate 

Date/Time 

IssuedAt 

Text(15) 

BOARDING 

BOK) 

AutoNumber 

Key 

OFFICER 

BOName 

Text(25) 

Ranic 

Text(7) 

Qual 

Text(25) 

QualDate 

Date/Time 

PortID  FK 

Number 

FK 

PORT 

PortID 

AutoNumber 

Key 

UnitName 

Text(25) 

Street 

Text(20) 

City 

Text(20) 

State 

Text(4) 

Zip 

Number 

PhoneNo 

Text(15) 

Email 

Text(35) 

BOARDING¬ 

CaseNum  FK 

Number 

Key/FK 

BOARDING 

BOID_FK 

Number 

Key/FK 

OFFICER 

DEFRES 

DefID_FK 

Number 

Key/FK 

CaseNum_FK 

Number 

Key/FK 

Resolution 

Text(lOO) 

CaseNumRes_  FK 

Number 

FK 

117 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


118 


APPENDIX  C.  REPORTS  WEB  PAGE  CODE 


This  appendix  provides  the  code  behind  the  web  pages  created  for  the 
implementation  of  RePortS. 

A.  HOME.HTM 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title>Prototype  Home  Page</title> 

</head> 

<body> 

<centerximg  src=''images/medbar.jpg"  width="368"  height- ’39"  alt="" 
border="0"><br> 

<hr  size="3"  width="100%"> 

<strongxfont  face="arial"  size="5">WeIcome  to  the  PSC  prototype  web 
site !  </fontx/  strong> 

<hr  size="3"  width="100%"> 

<centerxbxbig>Agents</bigx/bx/center> 

<a  href="vessel_entry.htm">Click  here  to  give  notice  of  vessel  arrival.</axbr> 

<hr  size="3"  width="100%"> 

<centerxbxbig>Coast  Guard</big></b></center> 

<a  href="cg_enter_port.asp">Click  here  to  view  vessel  arrival  list.</a><br> 

<a  href="cg_enter_portl.asp">Click  here  to  view  vessels  selected  for  boarding.</axbr> 
<a  href="cg_enter_port2.asp">Click  here  to  view  vessel  boardings  to  review.</a><br> 
<a  href="cg_enterjport3.asp">Click  here  to  enter  vessel  departures.</a> 

<img  src=="images/rc_rod2.gif'  width="538"  height="6"  alt=""  border="0"> 

</body> 

</html> 

B.  CG_ENTER_PORT.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title>CG  Enter  Port</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"> 

<body> 

<hr  size="3"  width=’T00%"xbr> 

<form  action="cg_port_arrivals.asp"  method="POST"  name="cgenterport"> 

Enter  Your  Port  Name:  <!--#include  file="portdown.asp"— > 
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<br><br> 

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

<input  type="submit"  value="Submit"> 

</form> 

</body> 

<img  src="images/rc_rod2.gif'  width="538"  height="6"  border="0"><br> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 

C.  PORTDOWN.ASP 

<% 

SQLPORT="SELECT  PortE),  UnitName  FROM  PORT" 
set  connport  =  server.createobject("ADODB.Connection") 
connport.open  "test2" 
set  ports=connport.execute(SQLPORT) 

%> 

<select  name="PortID"> 

<%  do  while  not  ports.eof  %> 

<Option  value  =  "<%=  ports(O)  %>">  <%=  ports(l)  %></Option> 
<%ports.movenext 
loop%> 

</select> 

<%  connport.close  %> 

D.  CG_PORT_ARRIVALS.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 

<head> 

<title>List  of  Vessel  Arrivals</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height— '39"  border="0"> 

<body> 

<hr  size="3"  width="100%"xbr> 

<% 

port  =  Request.Form("PortID") 

'set  up  SQL  to  get  vessel  recordset 

SQL=  "SELECT  CaseNum,  ArrivalDate,  Priority,  Vin_FK,  PartyID_FK  FROM 
BOARDING  WHERE  PortID_FK  =  "  &  port  &  "  AND" 

SQL=  SQL  &  "  Type  =  'NOBD'  AND  Closed  =  False  ORDER  BY  TPoints  DESC;" 
'get  port  name  for  completeness 

PSQL  =  "SELECT  UnitName  FROM  PORT  WHERE  PortID  =  ”  &.  port  & 

'set  up  connection  to  the  database 
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set  connl  =  server.createobject("ADODB.Coimection") 
connl.open  "test2" 

set  rsBoarding  =  connl  .execute(SQL) 
set  rsPort  =  connl  .execute(PSQL) 

%> 

The  vessels  listed  below  are  vessels  which  have  not  been  targeted  for  a  boarding.<br> 
The  list  is  presented  in  priority  order  with  those  scoring  the  most  points  in  <br> 
a  given  priority  class  listed  in  order  of  highest  number  of  points  to  lowest.<brxbr> 

<hr  size="3’’  width=’’70%"  align="left"> 

Select  the  vessels  you  want  to  target  for  a  boarding  and  click  on  the  "submit"  button. 
<form  action="cg_boarding  pick  confirmation.asp"  method="POST"  name="list"> 
<table  border> 

<Captionxb><big>List  of  Vessel  Arrivals  for  <%=rsPort(0)%x/bigx/bx/Caption> 
<THEAD> 

<TR> 

<rH>Chk</TH> 

<TH>Vessel  Name</TH> 

<TH>VIN</TH> 

<TH>Flag</TH> 

<TH>Arrival  Date</TH> 

<TH>  Agent  Name</TH> 

<TH>Priority</TH> 

</TR> 

</THEAD> 

<TBODY> 

<% 

do  while  not  rsBoarding.eof 

VSQL=  "SELECT  VslName,  FlagID_FK  FROM  VESSEL  WHERE  Vin  =  "  & 
rsBoarding(3)  & 

set  rsVessel  =  connl. execute(VSQL) 

FSQL=  "SELECT  CountryName  FROM  FLAGSTATE  WHERE  FlagID  =  "  & 

rsVessel(l)  &. ";" 

set  rsFlag  =  connl. execute(FSQL) 

ASQL=  "SELECT  PartyName  FROM  INTPARTY  WHERE  PartylD  =  "  8c 

rsBoarding(4)  &  ";" 

set  rsAgent  =  connl.execute(ASQL) 

%> 

<tr> 

<tdxinput  type="checkbox"  name="box"  value="<%=rsBoarding(0)%>"x/td> 
<td><%=rsV  essel(0)%x/td> 

<tdx%=rsBoarding(3)%x/td> 

<tdx%=rsFlag(0)%x/td> 

<td><%=rsBoarding(  1  )%></td> 

<tdx%=rsAgent(0)%></td> 
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<tdx%=rsBoarding(2)%x/td> 

</tr> 

<%rsBoarding.MoveNext 

loop%> 

</TBODY> 

</tablexbr> 

<input  type="submit"  value="Submit">&nbsp;<input  type="reset"> 

</form> 

</body> 

<img  src="iinages/rc_rod2.gif'  width="538"  heightr="6"  border="0"xbr> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 

E.  CG_BOARDING_PICK_CONnRMATION.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 

<head> 

<title>Confirmation  of  Vessels</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"> 

<body> 

<hr  size="3"  width='T00%"xbr> 

<% 

'get  today's  date 
dTDate  =  Date 

'set  up  coimection  to  the  database 

set  connl  =  server.createobject("ADODB.Connection") 
connl.open  "test2" 

'loop  through  the  checkboxes  passed  from  the  last  page 
For  Each  item  In  Request.Form("box") 

'update  record  to  indicate  vessel  is  selected  for  a  boarding 

USQL  =  "UPDATE  BOARDING  SET  Type  =  'BD',  BdngDate  = '"  &  dTDate  &  "' 
WHERE  CaseNum  =  "  &  item  & 
connl  .execute(USQL) 

Next 

%> 

Vessel(s)  selected  for  boardings  updated. 

<br> 

<^ody> 

<img  src=''images/rc_rod2.gif'  width=''538''  height=''6''  border=''0''xbr> 

<a  href=''home.htm''>Retum  to  Home  Page</a> 

</html> 
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F.  CG  VIEW  BOARDINGS.ASP 


<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title>Vessels  Selected  For  Boarding</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"> 

<body> 

<hr  size="3"  width='T00%"xbr> 

<% 

port  =  Request.Fonn("PortID") 

'set  up  SQL  to  get  vessel  recordset 

SQL=  "SELECT  CaseNum,  ArrivalDate,  Priority,  Vin_FK,  PartyID_FK  FROM 
BOARDING  WHERE  PortID_FK  =  "  &  port  &  "  AND" 

SQL=  SQL  &  "  Type  =  'BD'  AND  Closed  =  False  ORDER  BY  TPoints  DESC;" 

'get  port  name  for  completeness 

PSQL  =  "SELECT  UnitName  FROM  PORT  WHERE  PortID  =  "  &  port  & 

'set  up  connection  to  the  database 

set  corml  =  server.  createobject("ADODB.  Connection") 

connl.open  "test2" 

set  rsBoarding  =  connl  .execute(SQL) 
set  rsPort  =  connl  .execute(PSQL) 

%> 

The  vessels  listed  below  are  vessels  which  have  been  targeted  for  a  boarding.<br> 

The  list  is  presented  in  priority  order  with  those  scoring  the  most  points  in  <br> 
a  given  priority  class  listed  in  order  of  highest  number  of  points  to  lowest.<brxbr> 

<hr  size="3"  width="70%"  align="left"> 

To  download  the  vessel  case  information  for  the  boarding,  check  the  checkbox  next<br> 
to  the  vessel(s)  desired.  When  you  have  made  yoim  selections  click  on  the  "submit" 
button.<br> 

<form  action="cg_download_db.asp"  method="POST"  name="list"> 

<table  border> 

<Captionxb><big>Vessels  Selected  for  Boarding  at 
<%=rsPort(0)%></bigx/b></Caption> 

<THEAD> 

<TR> 

<TH>Chk</TH> 

<TH>Vessel  Name</TH> 

<TH>VIN</TH> 

<TH>Flag</TH> 

<TH>Arrival  Date</TH> 

<TH>  Agent  Name</TH> 

<TH>Priority</TH> 
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</TR> 

</THEAD> 

<TBODY> 

<% 

do  while  not  rsBoarding.eof 

VSQL=  "SELECT  VslName,  FlagID_FK  FROM  VESSEL  WHERE  Vin  =  "  & 
rsBoarding(3)  & 

set  rsVessel  =  connl.execute(VSQL) 

FSQL=  "SELECT  CountryName  FROM  FLAGSTATE  WHERE  FlagID  =  "  & 
rsVessel(l)  & 

set  rsFlag  =  connl.execute(FSQL) 

ASQL=  "SELECT  PartyName  FROM  INTPARTY  WHERE  PartylD  =  "  & 
rsBoarding(4)  & 

set  rs  Agent  =  connl  .execute(ASQL) 

%> 

<tr> 

<tdxinput  type="checkbox"  name="box"  value="<%=rsBoarding(0)%>"x/td> 
<tdx%=rsV  essel(0)%x/td> 

<tdx%=rsBoarding(3)%x/td> 

<tdx%=rsFlag(0)%x/td> 

<tdx%=rsBoarding(  1  )%x/td> 

<tdx%=rsAgent(0)%x/td> 

<tdx%=rsBoarding(2)%></td> 

</tr> 

<%rsBoarding.MoveNext 

loop%> 

</TBODY> 

</tablexbr> 

<input  type-'submit"  value="Subniit">&nbsp;<input  type="reset"> 

</fonn> 

</body> 

<img  src="iniages/rc_rod2.gif '  width="538"  height="6"  border="0"><br> 

<a  l^e^"home.htm">Retum  to  Home  Page</a> 

</html> 

G.  AGENTDOWN.ASP 

<% 

SQLAGENT="SELECT  PartylD,  PartyName  FROM  INTPARTY  WHERE  PartyRole 
'agent'" 

set  connagent  =  server.createobject("ADODB.Connection") 

connagent.open  "test2" 

set  agents=connagent.execute(SQLAGENT) 

%> 
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<select  name="AgentID"> 

<%  do  while  not  agents.eof  %> 

<Option  value  =  "<%=  agents(O)  %>">  <%=  agents(l)  %></C)ption> 
<%agents.movenext 
loop%> 

</select> 

<%  connagent.close  %> 

H.  ENTER_ARRIVAL.ASP 

<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<titIe>Enter  Vessel  AiTival</title> 

</head> 

<body> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border=''0"xbr> 

<hr  size=’'3"  width=’T00%"xbr> 

<% 

vin  =  Request.QuerystringC'vin") 

vslNanie=Request.Querystring("vslName") 

imo=Request.Querystring("imo")%> 

Enter  the  arrival  information  for  the  vessel  <%=vslName%>  IMO  number 
<%=imo%>.<br> 

<form  action="airival_reply.asp”  method="POST"  name="arrentry"> 

Arrival  Date:  &nbsp;<input  name="adate’'  type="text"  align="TOP"  size="15"xbr> 
Agent  Name:  <!-#include  file="agentdown.asp"-xbr> 

Arrival  Port:&nbsp;&nbsp;<!— #include  file="portdown.asp"--><brxbr> 

<input  name="vin"  type="hidden"  value="<%=vin%>’'> 

<input  name="vslName"  type="hidden"  value="<%=vslName%>"> 

<input  type="submit"  value="Submit">&nbsp;<input  type='Teset"> 

</foiTn> 

</body> 

<img  src="images/rc_rod2.gif’  width="538"  height="6"  border="0"><br> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 

I.  ARRIVAL_REPLY.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 

<!-  #Include  file="ADOVBS.INC"  -> 

<%  Language  =  VBScript  %> 

<html> 

<head> 
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<title> Arrival  accepted.</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"> 

<body> 

<hr  size="3"  width="100%"xbr> 

<!—  ADO  Connection  Object  used  to  create  recordset— > 

<% 

'Create  and  Open  Connection  Object 

Set  OBJdbConnection  =  Server.CreateObject("ADODB.Connection") 
OBJdbConnection.Open  "test2" 

'Create  and  Open  Recordset  Object 

Set  RsBoardingList  =  Server.CreateObject("ADODB.Recordset") 
RsBoardingList-ActiveConnection  =  OBJdbConnection 
RsBoardingList.CursorType  =  adOpenKeyset 
RsBoardingList.LockType  =  adLockOptimistic 
RsBoardingList.Source  =  "BOARDING" 

RsBoardingList-Open 
vin=Request.  form("  vin") 
agent=Request.fonn("AgentID") 
adate=CDate(Request.fonn("adate")) 
port=Request.  form(  "PortID") 
vslName  =  Request.fomi("vslName") 

RsBoardingList.AddNew 
RsBoardingList("ArrivalDate")  =  adate 
RsBoardingList("Vin_FK")  =  vin 
RsBoardingList("PortID_FK")  =  port 
RsBoardingList("PartyID_FK")  =  agent 
RsBoardingListC'Type")  =  "NOBD" 

RsBoardingList-Update 

RsBoardingList-MoveLast 

%> 

Arrival  accepted  for  the  vessel  <%=vslName%>  on  <%=adate%>.<brxbr> 

<% 

'declare  targeting  variables 

dim  iOwOp,  iFlag,  iClass,  iHistory,  iShipType,  iTotal,  iPriority 
'setup  variables  for  use  in  targeting 
'vin  =  Request.  QuerystringC  vin") 
dXoday  =  Date 

dOneYear  =  DateAdd("yyyy",  -1,  dToday)  'get  date  for  a  year  ago 
dXenYears  =  DateAdd("yyyy",  -10,  dXoday)  'get  a  date  for  ten  years  ago 
dSixMonths  =  DateAdd("m",  -6,  dXoday)  'get  a  date  six  months  ago 
'setup  query  to  get  vessel  info 

VSQL  =  "SELECX  VslName,  VslXype,  BldDate,  FlagID_FK,  ClassID_FK  FROM  " 
VSQL  =  VSQL  &  "VESSEL  WHERE  Vin  =  "  &  vin  & 
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'setup  query  to  get  owner  and  operator  for  vessel 

OSQL  =  "SELECT  PartyID_FK  FROM  [VESSEL-INTPARTY]  WHERE  Vin_FK  =  "  & 
vin  & 

'setup  query  to  get  boardings  for  the  vessel 

BSQL  =  "SELECT  CaseNum,  Type,  BdngDate,  VslDetained,  OpControl  FROM 
BOARDING  " 

BSQL  =  BSQL  &  "WHERE  Vin_FK  -  "  &  vin  &  "  AND  BdngDate  >  "  &  dOneYear  & 

M.lt 

5 

'get  record  sets  for  the  above  queries 
set  rsVessel  =  OBJdbConnection.execute(VSQL) 
set  rsOwOp  =  OBJdbConnection.execute(OSQL) 
set  rsBoarding  =  OBJdbConnection.execute(BSQL) 

'calculate  ship  type  targeting  numbers 
strVType  =  rsVessel(l) 
dBldDate  =  rsVessel(2) 

Select  Case  strVType 
Case  "TANK" 

iShipType  =  1 
Case  "PASS" 

iShipType  =  1 

Case  "GAS" 

iShipType  =  1 

Case  "FRT" 

'do  nothing 

Case  "Bulk" 

if  dBldDate  <  dTenYears  then 
iShipType  =  2 
End  if 

End  Select 

'Calculate  owner  operator  targeting  number 
if  rsOwOp.bof  and  rsOwOp.eof  then 
errOwOp  =  1 

strOwOpErr  =  "Owner  and  Operator  not  entered  in  database." 
iOwOp  =  0 
Else 

do  while  not  rsOwOp.eof 

OTSQL  =  "SELECT  TPoints  FROM  INTPARTY  WHERE  PartylD  =  "  & 
rsOwOp(O)  & 

rOwOp  =  OBJdbConnection.execute(OTSQL) 
iOwOp  =  iOwOp  +  rOwOp(O) 
rsOwOp.MoveNext 
loop 
End  If 

'get  Flag  targeting  number 
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FLSQL  =  "SELECT  TPoints  FROM  FLAGSTATE  WHERE  FlagID  =  "  &  rsVessel(3)  & 

II.  ft 

5 

rsFlag  =  OBJdbCoimection.execute(FLSQL) 
iFlag  =  rsFlag(O) 

’get  Class  targeting  number 
If  rsVessel(4)  =  Null  then 
errClass  =  1 

strClassErr  =  "Class  not  entered  in  database." 
iClass  =  0 
Else 

CLSQL  =  "SELECT  TPoints  FROM  CLASS  WHERE  ClassID  =  "  &  rsVessel(4)  & 
rsClass  =  OBJdbConnection.execute(CLSQL) 
iClass  =  rsClass(O) 

End  If 

'calculate  history  targeting  number 
if  rsBoarding.bof  and  rsBoarding.eofthen 
iHistory  =  2 
Else 

if  rsBoarding(l)  o  "NOBD"  and  rsBoarding(2)  <  dSixMonths  then 
iHistory  =  iHistory  +  1 

End  if 

do  while  not  rsBoarding.eof 
strType  =  rsBoarding(l) 
bDetained  =  rsBoarding(3) 
bOpControl  =  rsBoarding(4) 

Select  Case  strType 

Case  "CAS" 

iHistory  =  iHistory  +  1 
Case  "VIO" 

iHistory  =  iHistory  +  1 

End  Select 

if  bDetained  then  iHistory  =  iHistory  +  1 
if  bOpControl  then  iHistory  =  iHistory  +1 
rsBoarding.MoveNext 

loop 
End  If 

'Add  up  the  numbers  and  assign  priority 
If  errOwOp  =  1  Or  errClass  =  1  then 

strReply  =  "Expect  at  least  a  call  from  the  local  unit  for  more  information." 

Else 

iTotal  =  iOwOp  +  iFlag  +  iClass  +  iHistory  +  iShipType 
If  iTotal  >16  then 
iPriority  =  1 
Elself  iTotal  >  6  then 
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iPriority  =  2 
Elself  iXotal  >  3  then 
iPriority  ==  3 
Else 

iPriority  =  4 
End  If 
End  If 

'Store  the  points  and  priority  of  the  vessel  for  later  use 
newCase  =  RsBoardinglist(O) 

PPSQL  =  "UPDATE  BOARDING  SET  TPoints=  "  &  iTotal  &  ",  " 

PPSQL  =  PPSQL  &  "Priority="  &  iPriority  &  " " 

PPSQL  =  PPSQL  &  "WHERE  CaseNum="  &  newCase  &  ";" 
OBJdbConnection.execute(PPSQL) 

%> 

<hr  size="3"  width="70%"  align="lefl"xbr> 

Vessel  Grading  results  for  the  vessel  <%=rsVessel(0)%>.<br> 

<%if  errOwOp  =  1  then 

Response. Write("Grading  could  not  be  completed."  &  strReply  &  "  ") 

Response.  Write("The  information  missing  is: "  &  strOwOpErr  &  "  ") 

Elself  errClass  =  1  then 

Response.Write("Grading  could  not  be  completed."  &  strReply  &  "  ") 

Response.  Write("The  information  missing  is:  "  &  strClassErr  &  "  ") 

Else 

if  iPriority  =  4  then 

Response. Write("The  vessel  is  a  priority  4  vessel  do  not  expect  a  boarding.") 
Elself  iPriority  =  3  then 

Response. Write("The  vessel  is  a  priority  3  vessel  there  may  be  a  boarding.") 
Elself  iPriority  =  2  then 

Response.Write("The  vessel  is  a  priority  2  vessel  expect  a  boarding.") 

Elself  iPriority  =  1  then 

Response.Write("The  vessel  is  a  priority  1  vessel  it  will  be  boarded.") 

Response.Write("Expect  a  call  from  the  local  CG  unit  concerning  holding 
the  vessel  out  of  port.") 

End  If 
End  If 

OBJdbConnection.close 

%> 

<br> 

</body> 

<img  src="images/rc_rod2.gif'  width="538"  height="6"  bordei:="0"><br> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 
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J.  FLAGDOWN.ASP 


<% 

'set  up  SQL  query 

SQLFLAG="SELECT  FlagID,  CountryName  FROM  FLAGSTATE" 
set  connflag  =  server.createobject("ADODB.Connection") 
coimflag.open  "test2" 

'get  list  of  flags  and  country  names  from  database 
set  flags=connflag.execute(SQLFLAG) 

%> 

<select  name="FlagID"> 

<%  do  while  not  flags.eof  %> 

<Option  value  =  "<%=  flags(O)  %>">  <%=  flags(l)  %x/Option> 
<%flags.movenext 
loop%> 

</select> 

<%  connflag.close  %> 

K.  CG_TO_REVIEW.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 

<head> 

<title>Vessel  Cases  to  Review</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"> 

<body> 

<hr  size="3"  width="100%"xbr> 

To  review  one  of  the  vessel  boardings  from  the  list  below,  click  on  the  case  <br> 
number  to  pull  up  the  case  information.<br> 

<hr  size="3"  width="80%"  align="left"xbr> 

<% 

port  =  Request.Form("PortID") 

'set  up  SQL  to  get  vessel  recordset 

SQL=  "SELECT  CaseNum,  Type,  BdngDate,  Priority,  Vin  FK  FROM  BOARDING 
WHERE  PortID_FK  =  "  &  port  &  "  AND" 

SQL=  SQL  &  "  InProcess  =  True  AND  Closed  =  False  ORDER  BY  TPoints  DESC;" 
'get  port  name  for  completeness 

PSQL  =  "SELECT  UnitName  FROM  PORT  WHERE  PortID  =  "  &  port  & 

'set  up  connection  to  the  database 

set  connl  =  server.createobject("ADODB.Connection") 

conn  1. open  "test2" 

set  rsBoarding  =  corm  1  .execute(SQL) 
set  rsPort  =  connl.execute(PSQL) 
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%> 

<table  border> 

<Captionxb><big>Vessel  Boardings  at  <%=rsPort(0)%></bigx/b></Caption> 
<THEAD> 

<TR> 

<TH>Case  Number</TH> 

<TH>Boarding  Type</TH> 

<TH>Vessel  Name</TH> 

<TH>VIN</TH> 

<TH>Flag</TH> 

<TH>Boardmg  Date</TH> 

<TH>Priority</TH> 

</TR> 

</THEAD> 

<TBODY> 

<% 

do  while  not  rsBoarding.eof 

VSQL=  "SELECT  VslName,  FlagID_FK  FROM  VESSEL  WHERE  Vin  =  "  & 
rsBoarding(4)  & 

set  rsVessel  =  connl.execute(VSQL) 

FSQL=  "SELECT  CountryName  FROM  FLAGSTATE  WHERE  FlagID  =  "  & 
rsVessel(l)  & 

set  rsFlag  =  connl  .execute(FSQL) 

%> 

<tr> 

<tdxa 

href="cg  vsl  review  pg.asp?CaseNum=<%=rsBoarding(0)%>"x%=rsBoarding(0)%x 
/a></td> 

<tdx%=rsBoarding(  1  )%x/td> 

<tdx%=rs  V  essel(0)%></td> 

<tdx%=rsBoarding(4)%x/td> 

<tdx%=rsFlag(0)%x/td> 

<tdx%=rsBoarding(2)%x/td> 

<td><%=rsBoarding(3)%x/td> 

</tr> 

<%rsBoarding.MoveNext 

loop%> 

</TBODY> 

</table> 

<br><br> 

</body> 

<inig  src="iniages/rc_rod2.gif’  width="538"  height="6"  border="0"><br> 

<a  href="honie.htm">Retum  to  Homepage</a> 

</html> 
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L.  CG_VSL_REVIEW_PG.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 

<head> 

<title>Case  Review  Page</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height— '39"  border="0"> 

<body> 

<hr  size="3"  width="100%"xbr> 

<% 

caseNum  =  Request.Querystring("CaseNum") 

BSQL=  "SELECT  *  FROM  BOARDING  WHERE  CaseNum  = "  &  caseNum  & 

'set  up  connection  to  the  database 

set  connl  =  server.createobject("ADODB.Connection") 

conn  1. open  "test2" 

rsBoarding  =  connl  .execute(BSQL) 

'get  vessel  information 

VSQL  =  "SELECT  *  FROM  VESSEL  WHERE  Vin  =  "  &  rsBoarding(14)  & 
rsVessel  =  connl. execute(VSQL) 

FSQL  =  "SELECT  CountryName  FROM  FLAGSTATE  WHERE  FlagID  =  "  & 

rsVessel(ll)&";" 

rsFlag  =  connl. execute(FSQL) 

%> 

<centerxbigxb>Boarding  Case  Information</bx/bigx/centerxbr> 
<centerxixfont  color="blue">Items  in  blue  cannot  be  edited.</font></ix/center> 
<hr  size="3"  width="60%"xbr> 

<centerxform  action=""> 

<table  border> 

<thead> 

<tr> 

<th>VIN</th> 

<th>Vessel  Name</th> 

<th>IMO  Number</th> 

<th>Flag  State</th> 

</tr> 

</thead> 

<tr> 

<tdxfontcolor="blue"><%=rsVessel(0)%x/font></td> 

<tdxfont  color="blue"x%=rsVessel(2)%x/font></td> 

<tdxfont  color="blue"x%=rs  V  essel(  1  )%x/  font></td> 
<tdxfontcolor="blue"x%=rsFlag(0)%></fontx/td> 

</tr> 
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</table> 

<table  border> 

<thead> 

<tr> 

<th>Case  Number</th> 

<th>Boarding  Type</th> 

<th> Arrival  Date</th> 

<th>Priority</th> 

<th>Boarding  Date</th> 

<th>Boarding  Location</th> 

</tr> 

</thead> 

<tr> 

<tdxcenterxfont  color="blue"x%=rsBoarding(0)%x/fontx/centerx/td> 
<tdxinput  name="type"  type="text"  size="8"  value="<%=  rsBoarding(l)%>"x/td> 
<tdxinput  name="adate"  type="text"  size="10"  value="<%=rsBoarding(2)%>"x/td> 
<tdxcenterxfont  color="blue"x%=rsBoarding(4)%x/fontx/centerx/td> 
<tdxinput  name="bdngdate"  type="text"  size="8" 
value="<%=rsBoarding(5)%>"x/td> 

<tdxinput  name="bdngloc"  type="text"  size="15" 
value="<%=rsBoarding(6)%>"x/td> 

</tr> 

</table> 

<table  border> 

<thead> 

<tr> 

<th>Vessel  Detained?</th> 

<th>Op  Control  Imposed?</th> 

<th>Time  on  Boarding</th> 

</tr> 

</thead> 

<tr> 

<tdxcenterxinput  type="checkbox"  nanie=”detained" 
value="<%=rsBoarding(8)%>"x/centerx/td> 

<tdxcenterxinput  type="checkbox"  name="opcontrol" 
value="<%=rsBoarding(9)%>"xVcenterx/td> 

<tdxcenterxinput  nanie="bdngtime"  t5T5e="text"  size="5" 
value="<%=rsBoarding(  1 3)%>"x/centerx/td> 

</tr> 

</table> 

<table  border> 

<thead> 

<tr> 

<th>Boarding  Details</th> 
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</tr> 


</thead> 

<tr> 

<td> 

<textarea  name="detail"  rows=6  cols=30><%=rsBoarding(12)  %></textarea><br> 
<input  type="checkbox"  name="validate"  value="">Check  here  to  validate  case.<br> 
<input  type="button"  value="Submit"> 

</td> 

</tr> 

</table> 

</form> 

</center> 

</body> 

<img  src="images/rc_rod2.gif'  width='’538"  height="6"  border="0"><br> 

<a  l^ef="home.htm">Retum  to  Home  Page</a> 

</html> 

M.  VESSEL_ENTRY.HTM 

<!DOCTYPE  HTML  PUBLIC  "-/AY3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title>Vessel  Arrival  Entry  Page</title> 

</head> 

<body> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border=="0"  alt="CG  Bar" 
align="middle"> 

<hr  size="3"  width="100%"> 

<form  action="results.asp"  method="POST"  name="ehter"> 

<b>Vessel  Name:</bxinput  name="vesser'  type="text"  align  ="TOP" 
size— '30"xbrxbr> 

&nbsp;&nbsp;&nbsp;&nbsp;<input  type="submit"  value="Submit" 
align="MIDDLE">&nbsp;«&nbsp;<inputtype="reset"> 

</form> 

<img  src="images/rc_rod2.gif '  width="538"  height="6"  alt=""  border="0"xbr> 
</body> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 


N.  RESULTS.ASP 

<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 
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<head> 

<title>Pick  the  Vessel</title> 

</head> 

<body> 

<img  src="iniages/medbar.jpg"  width="368"  height="39"  border="0"  alt="CG 
Bar"xbr> 

<hr  size="3"  width="100%"xbr> 

<% 

'declare  variables 
Dim  vessel 
Dim  SQL 

'set  vessel  equal  to  what  user  typed  in 
vessel=Request.Form("vessel") 

'define  SQL  for  query 

SQL="SELECT  Vin,  MONumber,  VslName,  CountryName  FROM  VESSEL, 
FLAGSTATE  " 

SQL=  SQL  &.  "WHERE  VslName  ='"  &  vessel  & . 

SQL  =  SQL  &  "AND  VESSEL.FlagID_FK  =  FLAGSTATE.FlagID" 

'define  SQL  to  find  the  flag  name  for  each  vsl 
'create  the  connection 

set  conn  =  server.createobject("ADODB.Connection") 

conn.open"test2" 

set  results=conn.Execute(SQL) 

'test  to  see  if  any  records  found 
If  results.bof  and  results.eof  then 
Response. Write(" Vessel  not  found.  ")%xbr> 

<a  href="enter_new.asp?vslName=<%=vessel%>">Click  here  to  enter  vessel 
information.</a> 

<% 

Else 

Response. Write("Click  on  the  vessel  id  you  wish  to  provide  the  arrival  notice 

for.") 

do  while  not  results.eof 
%>  <br> 

<table> 

<tr> 

<tdxa  href="enter_arrival.asp?vin=<%=  results(O) 
%>&vslName=<%=results(2)%>&imo=<%=results(  1  )%>"><%=  results(  1 ) 
%x/ax/td> 

<tdx%=  results(2)%></td> 

<tdx%=results(3)  %></td> 

</tr> 

<% 

results.movenext 
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loop%>  <% 

End  if%> 

</table> 

<% 

conn.close 

%> 

</body> 

<img  src="images/rc_rod2.gif'  width="538"  height="6"  border="0"><br> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 

O.  ENTER_NEW.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 

<head> 

<title>Vessel  Entry</title> 

</head> 

<body> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"  alt="CG 
Bar"xbr> 

<hr  size="3"  width="100%"xbr> 

<%  vessel  =  Request.QuerystringC'vslName")  %> 

Please  enter  the  vessel  data  below:<br> 

<fonn  action="ack.asp"  method="POST''  name=''reply"> 

Vessel  Name:  &nbsp;<input  name— ’vslName"  type="text"  align=”TOP"  size="30" 
value="<%=vessel%>"xbr> 

IMO  Number:  <input  name='’IMO"  type="text"  align="TOP"  size=’T5"xbr> 

Build  Date:  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<input  name="BldDate"  type="text" 
align="TOP"  size="15">(If  not  Imown  please  leave  blank) 

<br> 

Flag:  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  <! -#include  file="flagdown.asp"-> 

<br> 

Vessel  Type:  &nbsp;&nbsp;&nbsp;<select  name="vtype"> 

<option  value="TANK">Tank  Ship</option> 

<option  value="FRT">Freight  Ship</option> 

<option  value="BULK">Bulk  Carrier</option> 

<option  value="PASS">Passenger  Ship</option> 

<option  value=''GAS">LPG/Gas  Carrier</option> 

</select> 

<br> 

<hr  size="3"  width="60%"  align="left"> 


136 


Arrival  Date:&nbsp;&nbsp;&nbsp;&nbsp;<input  name="adate"  type="text"  align=”TOP" 
size="20"xbr> 

Port: 

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 

&nbsp;&nbsp; 

<!— #include  file="portdown.asp"— ><br> 

Agent  Info:  &nbsp;&nbsp;&nbsp;&nbsp;<!— #include  file="agentdown.asp""><br> 
<br><input  type="submit"  value="Submit">&nbsp;&nbsp;<input  type="reset"> 

</form> 

</body> 

<img  src="images/rc_rod2.gif'  width="538"  height="6"  border="0"  alt="CG  Rod"> 
</html> 

P.  ACK-ASP 

<!DOCTYPE  html  PUBLIC  ’’-/AV3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title>Vessel  Entered  and  Arrival  Accepted</title> 

</head> 

<body> 

<img  src="images/medbar.jpg”  width="368"  height="39"  border="0"  alt="CG 
Bar"xbr> 

<hr  size="3"  width=’T00%"> 

<br> 

<% 

IMO  =  Request.Form("IMO") 
vslName  =  Request.Fonn("vslName") 

FlagID  =  Request.Form("FlagID") 
vtype  =  Request.Form("vtype") 

BldDate  =  CDate(Request.Fomi("BldDate")) 

vlen  =1 

bre  =  1 

depth  =  1 

prop  =  "unkn" 

snote  =  "none" 

'setup  Insert  query  to  create  the  vessel  in  the  database 

SQLINSERT  =  "INSERT  INTO  VESSEL  (IMONumber,  VslName,  VslType,  BldDate, 
Length,  Breadth,  Depth,  Propulsion,  SpecialNote,  FlagID_FK)  " 

SQLINSERT  =  SQLINSERT  &mp;  "VALUES  (" 

SQLINSERT  =  SQLINSERT  &mp;  IMO  &mp;  ",  " 

SQLINSERT  =  SQLINSERT  &mp; '""  &mp;  vslName  &mp;  "’,  " 

SQLINSERT  =  SQLINSERT  &mp;  ""’  &mp;  vtype  &mp; "',  " 

SQLINSERT  =  SQLINSERT  &mp;  &mp;  BldDate  &mp;  "',  " 
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SQLINSERT  -  SQLINSERT  &mp;  vlen  &mp;  ",  " 

SQLINSERT  =  SQLINSERT  &mp;  bre  &mp; ",  " 

SQLINSERT  =  SQLINSERT  &mp;  depth  &mp;  ",  " 

SQLINSERT  =  SQLINSERT  &mp;  "’"  &mp;  prop  &mp;  " 

SQLINSERT  =  SQLINSERT  &mp; . &mp;  snote  &mp;  "’, " 

SQLINSERT  =  SQLINSERT  &mp;  FlagID  &mp;  "); "  %>  <% 

'create  the  vessel  record 

set  conninsert  =  server.createobject("ADODB.Connection") 
conninsert.open  "test2" 
conninsert.execute(SQLINSERT) 

'get  vin  for  vessel  just  entered 

SQLV  =  "SELECT  Vin  FROM  VESSEL  WHERE  VslName  ='"  &mp;  vslName  &mp;'"" 
set  rVin  =  conninsert.execute(SQLV) 

'set  up  query  to  record  vessel  arrival  information 
adate  =  CDate(Request.Form("adate")) 
port  =  Request.Form("PortID") 
btype  =  "NOBD" 

agent  =  Request.Form("AgentID") 

Vin  =  rVin(O) 

SQLBD  =  "INSERT  INTO  BOARDING  (Type,  ArrivalDate,  Vin_FK,  PortID_FK, 
PartyID_FK)  " 

SQLBD  =  SQLBD  &mp;  "VALUES  (" 

SQLBD  =  SQLBD  &mp; . &mp;  btype  &mp; '",  " 

SQLBD  =  SQLBD  &mp;  «femp;  adate  &mp; '",  " 

SQLBD  =  SQLBD  &mp; . &mp;  Vin  &mp; '",  " 

SQLBD  =  SQLBD  &mp; . &mp;  port  &mp; '",  " 

SQLBD  =  SQLBD  &mp; '""  &mp;  agent  &mp; '")  " 
conninsert.execute(SQLBD) 

'get  the  port  name  for  acknowledgement 

SQLP  =  "SELECT  UnitName  FROM  PORT  WHERE  PortlD  =  "  &mp;  port  &mp; 

set  rName  =  conninsert.execute(SQLP) 

pName  =  rName(O) 

conninsert.close 

%>  <br> 

Arrival  accepted  for  the  <%=  vslName  %>  in  <%=pName%>  arriving  on 
<%=adate%>.<br> 

<br> 

<a  href="grading_results.asp?vin=&lt;%=Vin%&gt;">Click  here  to  view  the  grading 
results  on  the  vessel.</aximg  src="images/rc_rod2.gif '  width="538"  height="6" 
border="0"> 

</body> 

</html> 
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Q.  GRADING_RESULTS.ASP 


<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title>Vessel  Grading  Results</title> 

</head> 

<img  src=''images/medbar.jpg"  width="368"  height="39"  border=''0"xbr> 

<hr  size="3"  width='TOO%"xbr> 

<body> 

<% 

'declare  targeting  variables 

dim  iOwOp,  iFlag,  iClass,  iHistory,  iShipType,  iTotal,  iPriority 
'setup  variables  for  use  in  targeting 
vin  =  Request.QuerystringC'vin") 
dToday  =  Date 

dOneYear  =  DateAdd("yyyy",  -1,  dToday)  'get  date  for  a  year  ago 
dTenYears  =  DateAdd("yyyy",  -10,  dToday)  'get  a  date  for  ten  years  ago 
dSixMonths  =  DateAdd("m",  -6,  dToday)  'get  a  date  six  months  ago 
'setup  query  to  get  vessel  info 

VSQL  =  "SELECT  VslName,  VslType,  BldDate,  FlagID_FK,  ClassID_FK  FROM  " 
VSQL  =  VSQL  &,  "VESSEL  WHERE  Vin  =  "  &  vin  & 

'setup  query  to  get  owner  and  operator  for  vessel 

OSQL  =  "SELECT  PartyID_FK  FROM  [VESSEL-INTPARTY]  WHERE  Vin_FK  =  "  & 
vin  & 

'setup  query  to  get  boardings  for  the  vessel 

BSQL  =  "SELECT  CaseNum,  Type,  BdngDate,  VslDetained,  OpControl  FROM 
BOARDING " 

BSQL  =  BSQL  &  "WHERE  Vin_FK  =  "  &  vin  &  "  AND  BdngDate  >  "  &  dOneYear  & 

It.tt 

J 

'create  connection  to  the  database 

set  connl  =  server.  createobject("ADODB.  Connection") 

conn  1. open  "test2" 

'get  record  sets  for  the  above  queries 
set  rsVessel  =  connl  .execute(VSQL) 
set  rsOwOp  =  connl. execute(OSQL) 
set  rsBoarding  =  connl.execute(BSQL) 

'calculate  ship  type  targeting  numbers 
strVType  =  rsVessel(l) 
dBldDate  =  rsVessel(2) 

Select  Case  strVType 
Case  "TANK" 

iShipType  =  1 
Case  "PASS" 
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iShipType  =  1 

Case  "GAS" 

iShipType  =  1 

Case  "FRT" 

'do  nothing 

Case  "Bulk" 

if  dBldDate  <  dXenYears  then 
iShipType  =  2 
End  if 

End  Select 

'Calculate  owner  operator  targeting  number 
if  rsOwOp.bof  and  rsOwOp.eof  then 
errOwOp  =  1 

strOwOpErr  =  "Owner  and  Operator  not  entered  in  database." 
iOwOp  =  0 
Else 

do  while  not  rsOwOp.eof 

OTSQL  =  "SELECT  TPoints  FROM  INTPARTY  WHERE  PartylD  =  "  & 
rsOwOp(O)  & 

rOwOp  =  connl.execute(OTSQL) 
iOwOp  =  iOwOp  +  rOwOp(O) 
rsOwOp.MoveNext 
loop 
End  If 

'get  Flag  targeting  number 

FLSQL  =  "SELECT  TPoints  FROM  FLAGSTATE  WHERE  FlagID  =  "  &  rsVessel(3)  & 

ff.tf 

rsFlag  =  connl.execute(FLSQL) 
iFlag  =  rsFlag(O) 

'get  Class  targeting  number 
If  rsVessel(4)  =  Null  then 
errClass  =  1 

strClassErr  =  "Class  not  entered  in  database." 
iClass  =  0 
Else 

CLSQL  =  "SELECT  TPoints  FROM  CLASS  WHERE  ClassID  = "  &  rsVessel(4)  & 
rsClass  =  conn  1  .execute(CLSQL) 
iClass  =  rsClass(O) 

End  If 

'calculate  history  targeting  number 
if  rsBoarding.bof  and  rsBoarding.eof  then 
iHistory  =  2 
Else 

if  rsBoarding(l)  o  "NOBD"  and  rsBoarding(2)  <  dSixMonths  then 
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iHistory  =  iHistory  +  1 

End  if 

do  while  not  rsBoarding.eof 
strType  =  rsBoarding(l) 
bDetained  =  rsBoarding(3) 
bOpControl  =  rsBoarding(4) 

Select  Case  strType 

Case  "CAS" 

iHistory  =  iHistory  +  1 
Case  "VIO" 

iHistory  =  iHistory  +  1 

End  Select 

if  bDetained  then  iHistory  =  iHistory  +  1 
if  bOpControl  then  iHistory  =  iHistory  +1 
rsBoarding.MoveNext 

loop 
End  If 

'Add  up  the  numbers  and  assign  priority 
If  errOwOp  =  1  Or  errClass  =  1  then 

strReply  =  "Expect  at  least  a  call  from  the  local  unit  for  more  information." 

Else 

iTotal  =  iOwOp  +  iFlag  +  iClass  +  iHistory  +  iShipType 
If  iTotal  >  16  then 
iPriority  =  1 
Elself  iTotal  >  6  then 
iPriority  =  2 
Elself  iTotal  >  3  then 
iPriority  =  3 
Else 

iPriority  =  4 
End  If 
End  If 

%> 

Vessel  Grading  results  for  the  vessel  <%=rsVessel(0)%>.<br> 

<%if  errOwOp  =  1  then 

Response.Write("Grading  could  not  be  completed."  &  strReply  &  "  ") 
Response.Write("The  information  missing  is:  "  &  strOwOpErr  &  "  ") 

Elself  errClass  =  1  then 

Response.Write("Grading  could  not  be  completed."  &  strReply  &  "  ") 

Response.  Write("The  information  missing  is:  "  &  strClassErr  &  "  ") 

Else 

if  iPriority  =  4  then 

Response. Write("The  vessel  is  a  priority  4  vessel  do  not  expect  a  boarding.") 
Elself  iPriority  =  3  then 
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Response. Write("The  vessel  is  a  priority  3  vessel  there  may  be  a  boarding.") 
Elself  iPriority  =  2  then 

Response.Write("The  vessel  is  a  priority  2  vessel  expect  a  boarding.") 

Elself  iPriority  =  1  then 

Response.Write("The  vessel  is  a  priority  1  vessel  it  will  be  boarded.") 

Response.  WriteC'Expect  a  call  from  the  local  CG  imit  concerning  holding 
the  vessel  out  of  port.") 

End  If 
End  If 
conn  1. close 
%> 

</body> 

<img  src="images/rc_rod2.gif'  width="538"  height="6"  border="0"> 

</html> 

R.  CG_NO_BOARDS.ASP 

<!DOCTYPE  HTML  PUBLIC  "-//W3C//DTD  HTML  4.0  Transitional//EN"> 

<html> 

<head> 

<title> Vessels  in  Port</title> 

</head> 

<img  src="images/medbar.jpg"  width="368"  height="39"  border="0"> 

<body> 

<hr  size="3"  width=’T00%"xbr> 

<% 

port  =  Request.Form("PortID") 

'set  up  SQL  to  get  vessel  recordset 

SQL=  "SELECT  CaseNum,  ArrivalDate,  DateClosed,  Vin_FK,  PartyID_FK  FROM 
BOARDING  WHERE  PortID_FK  =  "  &  port  &  "  AND" 

SQL=  SQL  &  "  Type  =  "NOBD'  AND  Closed  =  False  ORDER  BY  ArrivalDate;" 

'get  port  name  for  completeness 

PSQL  =  "SELECT  UnitName  FROM  PORT  WHERE  PortlD  =  "  &  port  & 

'set  up  connection  to  the  database 

set  connl  =  server.createobject("ADODB.Connection") 
conn  1. open  "test2" 

set  rsBoarding  =  connl  .execute(SQL) 
set  rsPort  =  connl  .execute(PSQL) 

%> 

This  is  the  list  of  vessels  in  the  port  that  were  not  boarded.  Select  the  vessels  which 
have<br> 

departed  by  checking  the  check  box  and  enter  the  departure  date  in  the  departure  date 
field.<br><br> 

<hr  size="3"  width="70%"  align="left"> 
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When  finished,  click  on  the  "submit"  button. 

<form  action="cg_nobd_confinnation.asp"  method="POST"  name="list"> 

<table  border> 

<Captionxb><big>List  of  Not  Boarded  Vessels  in  Port  for 
<%=rsPort(0)%></bigx/b></Caption> 

<THEAD> 

<TR> 

<TH>Chk</TH> 

<TH>  Vessel  Name</TH> 

<TH>VIN</TH> 

<TH>Flag</TH> 

<TH> Arrival  Date</TH> 

<TH> Agent  Name</TH> 

<TH>Date  Departed</TH> 

</TR> 

</THEAD> 

<TBODY> 

<% 

do  while  not  rsBoarding.eof 

VSQL=  "SELECT  VslName,  FlagID_FK  FROM  VESSEL  WHERE  Vin  =  "  & 

rsBoarding(3)  &  ";" 

set  rsVessel  =  connl.execute(VSQL) 

FSQL=  "SELECT  CountryName  FROM  FLAGSTATE  WHERE  FlagID  =  "  & 

rsVessel(l)  &  ";" 

set  rsFlag  =  connl  .execute(FSQL) 

ASQL=  "SELECT  PartyName  FROM  INTPARTY  WHERE  PartyE)  =  "  & 
rsBoarding(4)  8c 

set  rsAgent  =  connl.execute(ASQL) 

%> 

<tr> 

<tdxinput  type="checkbox"  name="box"  value="<%=rsBoarding(0)%>"x/td> 
<tdx%=rsV  essel(0)%x/td> 

<tdx%=rsBoarding(3)%x/td> 

<tdx%=rsFlag(0)%x/td> 

<tdx%=rsBoarding(  1  )%x/td> 

<tdx%=rsAgent(0)%></td> 

<tdxinput  name="close"  type="text"  value="<%=Date%>"x/td> 

</tr> 

<%rsBoarding.MoveNext 

loop%> 

</TBODY> 

</tablexbr> 

<input  type="submit"  value="Submit">&nbsp;<input  type="reset"> 

</fonn> 
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</body> 

<img  src="images/rc_rod2.gif'  width="538"  height="6"  bordei="0"><br> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 

S.  CG_NOBD_CONFIRMATION.ASP 

<!DOCTYPE  HTML  PUBLIC  "-/AV3C//DTD  HTML  4.0  Transitional//EN"> 
<html> 

<head> 

<title>Confirmation  of  Vessel  Departure</title> 

</head> 

<img  src="images/medbar.jpg"  width="368''  height="39"  border=''0"> 
<body> 

<hr  size="3”  width='T00%"xbr> 

<% 

'set  up  connection  to  the  database 

set  connl  =  server.createobject("ADODB.Connection") 

connl.open  "test2" 

'loop  through  the  checkboxes  passed  from  the  last  page 
For  Each  item  In  Request.Form("box") 

'update  record  to  indicate  vessel  is  selected  for  a  boarding 
USQL  =  "UPDATE  BOARDING  SET  Closed  =  True,  DateClosed  = '"  & 
Request.Form("close")  &  '"  WHERE  CaseNum  =  "  &  item  & 
connl  .execute(USQL) 

Next 

%> 

Vessel(s)  selected  for  departure  updated. 

<br> 

</body> 

<img  src="images/rc_rod2.gif '  width="538"  height="6"  border="0"xbr> 

<a  href="home.htm">Retum  to  Home  Page</a> 

</html> 
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